# Managed Postgres: What Lakebase Actually Takes Off Your Plate > Source: > Published: 2026-09-14 23:36:59+00:00 See what Lakebase actually automates in managed Postgres — patching, scaling, failover, and backups — and where responsibility still sits with you. Every Postgres vendor calls itself "managed." Few of them agree on what that word covers. Some mean they patch the operating system (OS) and leave the rest to the database team. Others mean the database scales, handles failures, and backs itself up without anyone on the team touching a config file. Managed Postgres is a database service where the provider operates the underlying infrastructure and handles core database operations such as patching, scaling, failover, and backups, so the database team spends less time on maintenance and more time building the application that runs on top of it. The more of those operations the provider owns, the less database administration stays with the customer. That distinction matters more as Postgres moves into AI applications. The database may now hold application state, conversation history, embeddings, and agent data alongside traditional transactional workloads, so the operational surface extends beyond keeping the database running. Lakebase Postgres takes that managed approach to serverless Postgres, combining automatic scaling, PostgreSQL compatibility, recovery, and Databricks integrations. The question is how much operational work it actually removes. Think of [managed Postgres](https://answers.databricks.com/fully-managed-postgres) like handing over the keys to a database. How much a team hands over depends on the provider. At one end, the database team still handles the server, backups, failover, and scaling. At the other, a fully managed service takes care of the operational work for the team, not just the infrastructure underneath it. Most providers sit somewhere in between, handling the VM and network while leaving some database operations, scaling decisions, failover configuration, and backup policy to the team. A provider can patch the OS and call the database managed while the team is still responsible for the work that keeps it available and recoverable. Patching, scaling, failover, and backups are a good place to draw that line. A managed service also determines how much of the security, recovery, migration, AI workloads, and developer tooling around Postgres your team still has to own. Managed Postgres is a service where the provider operates the database infrastructure and handles core operational tasks such as patching, scaling, failover, and backups. A fully managed service takes responsibility for those operations, so your team can focus on building against Postgres rather than running it. The clearest test of where a service falls on that spectrum is whether it takes these four operational tasks off the team's plate: A managed provider should apply OS patches, minor PostgreSQL versions, and routine maintenance like vacuum tuning without the database team scheduling or executing any of it by hand- the opposite of self-hosted Postgres, where all of that sits with them. Major version upgrades still need planning, since extensions and application behavior can shift, but a good provider keeps that involvement to a minimum and makes the upgrade path clear. Capacity should adjust to the workload without platform engineers resizing infrastructure by hand: vertical scaling for more compute or memory, read replicas for read traffic, and ideally serverless scaling that removes the decision entirely. [Lakebase's autoscaling](https://www.databricks.com/blog/beyond-provisioning-developers-guide-databricks-lakebase-autoscaling) is one example in production, enabling [5x faster Postgres writes](https://www.databricks.com/blog/how-lakebase-architecture-delivers-5x-faster-postgres-writes) than standard Postgres. The real test is a traffic spike: if the database team is watching utilization and waiting on a resize, scaling is still their job. The database should stay up when infrastructure fails, without an on-call engineer manually promoting a replica at 2 a.m. Some providers handle this with standby instances that take over automatically; [others, like Lakebase, replace the failed compute outright since it holds no durable local state](https://www.databricks.com/blog/how-lakebase-architecture-stays-resilient-cloud-failures). Still, not every provider fails over at the same speed or with the same data loss. Some lose seconds of writes in the process; others lose none. That's the detail worth checking before trusting the label, including whether failover exists and what happens to in-flight writes when it kicks in. Automatic backups and a restore process teams can run without a support ticket are the baseline. Point-in-time recovery (PITR), restores to a specific moment instead of just the last snapshot, which matters when a bad migration corrupts data mid-afternoon. A full region going down is a bigger problem, measured by Recovery Time Objective (RTO), how long you're down, and Recovery Point Objective (RPO), how much data you can afford to lose, and a provider without defined numbers for both doesn't have a disaster recovery plan, just a guess. A managed database should encrypt data at rest and in transit, control who can access it, and give data teams visibility into database activity. That means: A migration can look straightforward until the new database doesn't support an extension, configuration, or [PostgreSQL](https://docs.databricks.com/aws/en/oltp/projects/postgres) feature an application relies on. Check what the application depends on before moving anything. Here are the key things to consider when migrating an existing PostgreSQL database: Postgres can be a strong fit for AI applications when an application needs transactional state and vector search in the same system. That comes down to four things: pgvector as the extension that makes it possible, vector search for retrieval, large language model (LLM) memory for persisting state between requests, and agent workloads that need both at once. [pgvector](https://www.databricks.com/blog/what-is-pgvector) adds a vector data type and similarity search indexing directly inside Postgres, so embeddings live next to the rest of your application data instead of in a system of their own. The tradeoff is that a separate vector database means keeping embeddings and operational data in sync becomes its own engineering problem, which pgvector removes for workloads that don't need a dedicated vector store. pgvector lets you store embeddings and use approximate nearest neighbor (ANN) indexes to find similar vectors efficiently as the dataset grows, which is what makes semantic search, retrieval-augmented generation, and meaning-based matching possible inside Postgres. The right indexing strategy still depends on dataset size and query patterns, so pgvector doesn't remove the need to evaluate performance for your specific workload. LLM applications need somewhere to keep state between requests, including conversation history, user preferences, retrieved documents, and tool results. Postgres can store that state as ordinary relational data while pgvector handles the embeddings in the same database. For workloads needing specialized vector retrieval at very large scale, a dedicated vector database may still make sense, but many AI applications can keep operational state and retrieval together. Agents continuously read and update state as they run. They track conversations, store intermediate results, and record tool calls, which makes the database part of the agent's execution layer rather than just somewhere to retrieve context. A [database built for AI agent workloads](https://www.databricks.com/database-for-ai-agents) needs to support both that constantly-changing transactional state and the retrieval the agent uses to find relevant context, in one system. Beyond running production workloads, Postgres needs to support how your team actually builds. That means connections don't become a bottleneck as you scale, and testing schema changes doesn't mean risking production data. Postgres has a finite limit on how many connections it can hold at once, and application instances scaling horizontally can hit that limit before compute or storage becomes the bottleneck. Connection pooling reuses established database connections across requests instead of opening a new connection for each one. In a managed service, what matters is whether pooling is built in or something your team has to operate separately. Testing schema changes against production data means risking production or maintaining a staging database that drifts out of sync over time. [Database branching](https://www.databricks.com/blog/database-branching-postgres-git-style-workflows-databricks-lakebase) creates an isolated environment from an existing database state or point-in-time snapshot, so developers can test migrations against realistic data, work like [evolutionary database development](https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebase), and delete the branch once it's no longer needed. [Lakebase's](https://www.databricks.com/product/lakebase) approach becomes clearer when you map it against the core jobs managed Postgres should handle: The table below shows which database operations Lakebase handles and which ones still stay with the database team: | **Dimension** | **What Lakebase handles** | |---|---| | Patching | Automatic PostgreSQL, security, OS, and compute updates | | Scaling | Automatic scaling, including scale-to-zero when idle | | Failover | Automatic failover to secondary compute within a region | | Backups and Recovery | Point-in-time restore with configurable 2-30 day history, plus scheduled snapshots for additional backup protection | | Disaster recovery | Private Preview, AWS only. Periodic replication with manual failover and customer-managed recovery procedures. | | Encryption | At rest and in transit, customer-managed keys available | | Access control | PostgreSQL roles and permissions, with Unity Catalog integrations for broader governance. | | Extensions | pgvector, PostGIS, and other supported PostgreSQL extensions | | Connection pooling | Built-in PgBouncer | | Branching | Copy-on-write, no duplicated storage | | Lakehouse integration | Synced tables and Change Data Feed | | Pricing | Serverless, scales with workload, suspends when idle. Storage billed separately. | Patching, scaling, failover, and backups all run automatically per the table above. Disaster recovery is the exception: still Private Preview, AWS only, with manual failover and customer-managed recovery procedures behind it. That's the detail worth checking before counting on Lakebase for anything spanning regions. [Learn more about Databricks Lakebase](https://www.databricks.com/product/lakebase). "Managed" means something different depending on who's selling it, from patching the OS and calling it done to owning the full weight of running a production database: scaling, failover, backups, security, migration, AI workloads, and the developer experience around all of it. Lakebase clears that bar on most of it. Patching, scaling, and failover run without your team stepping in; point-in-time recovery is built in, and security, extensions, connection pooling, and branching all come with the service. Cross-region disaster recovery is the one exception, still in Private Preview with manual failover, not the same automatic protection Lakebase provides within a region. For teams evaluating managed Postgres, the important question is how much of the operational work actually leaves their plate. [Lakebase](https://www.databricks.com/product/lakebase) handles most of that work within a region, while cross-region disaster recovery remains an area where teams still have responsibilities. Self-hosted Postgres puts every operational task on the database team: patching, scaling, failover, backup policy, disaster recovery. Managed Postgres shifts some or all of that to the provider, but the amount shifted varies widely. Partially managed services handle infrastructure and leave the rest to the customer. Some fully managed services also include security tooling, migration assistance, and developer workflows such as database branching. Serverless Postgres is a managed database model where compute scales automatically with demand, removing the need to provision a fixed instance size. Some providers scale compute to zero when the database is idle, while others keep a baseline of capacity. Pricing typically follows the compute used rather than a permanently provisioned instance. Database branching creates an isolated, copy-on-write branch of a database without duplicating the underlying storage. Each branch can hold its own compute and data changes without affecting production. Teams use it to test schema migrations against real data, spin up a branch per pull request, or restore a branch from a specific point in time, then delete it once the work is done. Subscribe to our blog and get the latest posts delivered to your inbox.