How Database Labs Postgres as a Service Started
Database Labs came about based on a simple realization: every system needs a database, and when you're using a database commercially, it has to be far more robust than just installing PostgreSQL itself. It needs a whole support ecosystem around it. That's what we do.
Database Support Ecosystem
When your business depends on the data in the database being accurate and highly available, you need to create a set of support tools and processes around Postgres to tend and manage it.
You need backups, you need redundant servers with automatic failover, you need 24/7 monitoring and alerting, you need performance tuning, and you need someone to stay on top of security patches.
We'd built and rebuilt this same basic PostgreSQL support infrastructure over and over for many different projects. We realized that we could turn it into a pushbutton operation -- a database as a service. Everyone wants this, and nobody wants to do it themselves.
DBaaS Offerings
Existing Postgres as a service systems fell short in different ways. They’re ridiculously expensive. Many use vendor lock-in as a customer retention strategy -- they hold your data hostage to keep you as a customer. Most are doing many other things in addition running Postgres as a service, leading to a dilution of focus and energy. We decided to do it better and build the Postgres as a Service we’ve always wanted.
Still self-hosting your database?
Many companies still self-host their databases. All of this PostgreSQL support infrastructure is utterly incidental to building the app itself, which is where most developers actually want to be spending their time.
As a result, we’ve seen too many companies simply skip one or more of these things -- not because they think they’re unimportant, but because they think that they’re less important than other things they could be doing.
Time is the most precious resource of any company, and often it’s allocated away from unglamorous tasks like configuring continuous offsite backups or regularly running test backup restorations.
Nonetheless, if the data in the database is actually important to your business, you have to do these things. If you don’t, sooner or later you’ll lose data. Since they’re important in a business sense, yet nobody wants to spend time doing them, this sounds like a great business, right?
Production Postgres
Let’s take a look at each of the major components of our turnkey PostgreSQL Database as a Service and see what’s involved.
- Flexible Cloud Hosting: you get the best performance when your database isß physically near your app servers -- ideally, in the same data center. We currently run Postgres databases in DigitalOcean and Amazon AWS, with more clouds on the horizon.
- Operating System: our systems run Ubuntu Linux.
- PostgreSQL itself: we run Postgres 9.4, with all common extensions such as PostGIS pre-installed.
- Monitoring: We’ve instrumented numerous aspects of the operating system and Postgres itself: CPU usage, memory usage, free disk space, I/O bandwidth, network traffic, and many more esoteric metrics. Every node continuously reports its statistics to an offsite system monitoring server, where a variety of conditions can trigger an alert to our human staff.
- Alerting: A staff member is on pager duty 24/7, so that we can catch anomalies before they become big problems. Daily Snapshots: Every night, we take a full offsite backup snapshot of your database.
- Continuous Backups: During the day, every change made to our databases is immediately shipped offsite and added to the backup archive as it happens. No change is ever not backed up.
- Point in Time Recovery: By restoring a snapshot and replaying these changes in order on top of it, we can rewind your database to the state it was in at any desired moment in time.
- Backup Testing: Our staff run through restoring Postgres backups regularly to test the systems and keep our skills sharp. When the time comes, we can do a backup restoraton fast and accurately.
- High Availability: A “hot standby” mirrors every event that happens on the prinary server as it happens. In the unlikely event that the primary fails, the hot standby is automatically promoted to take over as the new primary, and a new hot standby is added.
- Read-Only Replicas: For read-heavy workloads such as reporting and analytics, we can create any number of read-only replica databases that mirror the primary server.
- Management Console: Create and destroy databases as needed with the touch of a button.
- REST API: Get full programmatic access to the system. Create and destroy databases with a simple HTTP request.
- Tech Support: Finally, sometimes you need help. It happens. Call us anytime, day or night, for lightning quick responses to any issues.
In coming posts, we’ll look at each of these systems in more detail, as well as how Postgres itself works.