A request lands on a replica
Private Cloud scales the app horizontally within the bounds you set, on a schedule if the peak is known.
LaravelCloud
Choosing a database
A partnership story
Postgres at scale.
A private line next door.
Laravel works directly with PlanetScale to bring its Postgres to Private Cloud customers whose databases have outgrown the ordinary. The application stays in Laravel's building; the database sits in PlanetScale's; the traffic between them stays off the public internet.
Follow the line
The idea in one line Laravel runs the app, PlanetScale runs the database, and a private line joins them.
Two operators, one systemPrivate Cloud and PlanetScale
Operated by Laravel
Private Cloud
- Dedicated cluster, nodes across AZs
- Managed queues, autoscaling
- ElastiCache beside the app
- Nightwatch on every query
Operated by PlanetScale
PlanetScale Postgres
- One primary, replicas in other AZs
- PgBouncer pooling on port 6432
- Metal: local NVMe storage
- Neki: sharding, in preview
Status: provisioned and billed through the Laravel team; not yet self-serve in the dashboard
Through Laravel
What has been said, and what has shipped
Announced on X.
Running in production.
On 11 September 2026 Taylor Otwell wrote that Laravel works directly with PlanetScale to bring its databases to Private Cloud customers running Postgres at scale, and that Node, Python and Go apps are welcome too. It is provisioned and billed through the Laravel team, so a customer deals with one vendor and one bill. There is no self-serve docs page for it yet. Sportmonks already runs on it.
Shipped, documentedRDS Postgres 18 on Private Cloud
Provisioned from the dashboard inside the dedicated VPC, with Multi-AZ, read replicas and point-in-time recovery.
Through LaravelPlanetScale Postgres for Private Cloud
Provisioned and billed by the Laravel team: one contract, one bill. Ask the Cloud team; it is not a self-serve resource yet.
In productionSportmonks
Twelve applications on Private Cloud, reading from a 450 GB primary PlanetScale database.
Sources: Monitor 236 (Taylor Otwell on X, 11 September 2026, post); RDS docs and docs index, read 8 October 2026; Monitor 494 (RDS Postgres on Private Cloud, 2 March 2026); Monitor 993 (Sportmonks); provisioning and billing confirmed by the Laravel Cloud team, 8 October 2026.
The Postgres options, side by side
Two good databases.
One choice.
RDS on Private Cloud is the documented default and suits most workloads. PlanetScale is the option for teams whose Postgres is the hardest-working part of the system. Descriptions of PlanetScale are in PlanetScale's own words.
RDS Postgres on Private Cloud
AWS RDS Postgres 18, created from the Cloud dashboard inside your dedicated VPC and attached to an environment like any other Cloud database.
- Status
- Shipped and documented
- Provisioned
- Cloud dashboard; up to 20 minutes to create
- Availability
- Single-AZ, up to 15 read replicas, or Multi-AZ with failover
- Recovery
- Point-in-time, up to 30 days; restores to a new cluster
PlanetScale Postgres
A "fully-managed PostgreSQL-compatible database", in PlanetScale's words. On Metal it runs on direct-attached NVMe drives rather than network-attached storage.
- Status
- Through Laravel for Private Cloud, provisioned and billed by Laravel; in use by Sportmonks
- Topology
- One primary for writes; replicas in separate availability zones, promoted on failure
- Pooling
- PgBouncer on port 6432; direct connections on 5432
- Clouds
- Metal runs on AWS and GCP
Neki
"Sharded Postgres from PlanetScale". The post Taylor quoted on 11 September said Neki could be tried that day. PlanetScale advises against production use during the preview.
- Status
- Platform preview since 10 September 2026
- For
- Postgres that has outgrown one primary
- On Private Cloud
- Not stated [VERIFY]
Introducing Neki, PlanetScale blog; Monitor 236
PlanetScale pages read 8 October 2026. PlanetScale also published dedicated read replicas for Postgres on 6 October 2026; how they apply on Private Cloud is not stated [VERIFY].
One query, across the line
Pooling decides
the throughput.
Laravel
Eloquent opens a connection
Fifty replicas, each with PHP workers, each wanting a connection: this is where an unpooled database runs out.
It crosses the private line
In the load test, PlanetScale was reached over PrivateLink. Sportmonks' story does not say how it connects [VERIFY].
PgBouncer shares the connections
Point the app at port 6432 and tune the pool size and mode for the workload. Laravel 13.33's DB_POOLING flag is for Cloud-managed Postgres hostnames, not PlanetScale.
Reads go to a replica, writes to the primary
Laravel's read and write connections route the query; v13.33 configures the read host from DB_READ_HOST on Cloud.
Nightwatch sees the query
Add a customer ID as context and filter by it. Sportmonks found a years-old pagination problem that way.
“Tune your database before you blame your platform.”Laravel blog, K6 load testing on Laravel Cloud, 25 March 2026 · Monitor 588
Sources: Monitor 588 (Laravel's own test, not an independent benchmark, as its author says); Monitor 11 and v13.33.0 release notes, PRs 61668 (DB_POOLING rewrites .pg.laravel.cloud hosts to their -pooler endpoint) and 61665 (DB_READ_HOST), 22 September 2026; PlanetScale architecture docs; Monitor 993.
In production, in their figures
Sportmonks.
Every weekend, at peak.
A Netherlands sports data API with a team of 26, which moved twelve Laravel applications from self-managed servers to Private Cloud, with PlanetScale for the database and ElastiCache for the cache. The figures are Sportmonks' own, from their published story.
Requests
600MAPI requests a week, across football, Formula 1 and cricket- Zero infrastructure failures since going live
Database
24,000queries a second at peak, from a 450 GB primary- Four million rows read a second at peak
Jobs
1,000+jobs dispatched a second on match weekends- From 150 to 200 named Horizon queues to managed queues, after tuning on both sides
Cache
3Bcache events for the API product alone- Cursor pagination held in ElastiCache removed costly offset queries
Laravel Horizon does not support managed queues; failed jobs are handled in the Queues dashboard or the Cloud API, so a Horizon-shaped setup is redrawn rather than carried over (queues docs). Sportmonks says exact before-and-after figures are hard to give, as the old setup had little observability.
Laravel runs the app.
PlanetScale runs the database.
Three questions for a team with heavy Postgres: is your database or your compute the thing that fails at peak; have you tuned the pool before blaming either; and would a documented RDS cluster inside the VPC already be enough.