Neki is een gesharde Postgres-oplossing van PlanetScale, ontworpen om de prestatieplafonds van een enkele database-machine te doorbreken. In tegenstelling tot veel distributed databases maakt Neki gebruik van echte Postgres op elke shard, waardoor volledige SQL-ondersteuning en extensies behouden blijven.
De architectuur is opgebouwd uit vier componenten:
- Neki-routers: Deze spreken het standaard Postgres wire-protocol en routeren queries naar de juiste shards.
- Sharding en shard-groepen: Echte Postgres-clusters verspreid over availability zones, waarbij tabellen via een JSON-datatopologie worden gedistribueerd.
- Connection pooling: Sidecars die het verbindingsbeheer optimaliseren tussen de router en de database.
- Control plane: Verantwoordelijk voor health monitoring, failovers en coördinatie van workflows.
Een groot voordeel is dat onderhoudstaken zoals schemawijzigingen, versie-upgrades en resharding als volledig online workflows worden uitgevoerd. Gebruikers kunnen beginnen met een ongeshardde setup en pas overstappen op sharding wanneer de workload dit vereist. Neki is momenteel beschikbaar in een platform preview.
Introductie van Neki
Neki is nu beschikbaar in platform preview.
Neki is gebouwd op basis van lessen die we hebben geleerd tijdens acht jaar het beheren van enkele van de grootste gesharde MySQL-clusters ter wereld. Duizenden productie-workloads met miljoenen queries per seconde voor bedrijven waar zelfs een paar seconden downtime een publiek incident is. We weten wat het betekent om de grootste tier 0-workloads ter wereld te ondersteunen.
Toen we anderhalf jaar geleden PlanetScale Postgres lanceerden, wisten we dat we meer moesten doen. In die tijd hebben we duizenden klanten op PlanetScale verwelkomd, waarvan sommigen qua omvang kunnen wedijveren met onze grootste MySQL-klanten. Steeds opnieuw zagen we teams tegen het plafond van een enkele machine met Postgres aanlopen. Krachtigere hardware kocht hen tijd, maar aangezien klanten de bovengrens bereikten van wat één enkele machine kan presteren, merkten we dat er geen goede optie was om hen aan te bieden. Enter Neki.
Wat is Neki?
Neki is gesharde Postgres van PlanetScale. Hiermee kun je een Postgres-database schalen over meerdere machines, terwijl er op elke shard echte Postgres blijft draaien.
Je applicatie maakt verbinding met een Neki-router via het standaard Postgres wire-protocol, zodat je bestaande drivers, ORM's en connection strings blijven werken. Elke shard is een volledig Postgres-cluster met één primary en minstens twee replica's verspreid over drie availability zones. Er is geen aangepaste storage engine, waardoor extensies, SQL-ondersteuning en prestaties zich gedragen zoals je van Postgres gewend bent.
Je kiest zelf de shard-sleutel en bepaalt hoe tabellen worden gegroepeerd en gedistribueerd via een JSON-datatopologie. Schemawijzigingen, versie-upgrades, failovers, imports en resharding worden uitgevoerd als ingebouwde, volledig online workflows. Daarnaast profiteer je van de PlanetScale-functies waarop je al vertrouwt, waaronder Insights, schema-aanbevelingen, branching en MCP.
Je hoeft niet vanaf dag één te sharden. Je kunt Neki draaien als een enkele primary met replica's. Wanneer je dan toch uitgroeit uit één machine, is resharding een workflow die je uitvoert op het cluster dat je al hebt.
Waarom Neki?
De problemen die gepaard gaan met snelgroeiende Postgres-databases zijn bekend:
- Tabellen die te groot zijn om te vacuumen of te indexeren zonder het verkeer te beïnvloeden;
- Back-ups die uren duren;
- Connectielimieten;
- Onderhoudsvensters voor schemawijzigingen;
- Transaction wraparound en meer.
Je kunt overstappen naar een grotere instantie, maar uiteindelijk raak je de beschikbare machinegrootte kwijt, en de problemen schalen niet lineair naarmate je meer cores en IOPS toevoegt.
De bestaande oplossingen vragen elk om een concessie. Sharding op applicatieniveau verplaatst de routing naar je code. Distributed databases die "Postgres-compatibel" zijn, verbergen de shard-sleutel voor je, nemen je extensies weg en voegen complexiteit en latentie toe, wat lastig te beheren en te debuggen is.
Daarom hebben we Neki gebouwd volgens een aantal principes, waarvan de belangrijkste is: houd vast aan Postgres; omzeil het niet, simuleer het niet en wijk er niet van af.
Hoe werkt Neki?
We hebben Neki vanuit eerste principes architectuurd voor Postgres, met echte Postgres op elke shard. Het systeem bestaat uit vier bewegende delen:
Neki-routers
Je applicatie maakt eerst verbinding met een Neki-router. De router spreekt het Postgres wire-protocol, zodat je bestaande drivers en ORM's blijven werken met één enkele connection string. Een router beschikt over een volledige Postgres query parser, een distributed query planner, query buffering en meer. Hij analyseert je query, stelt een plan op om te bepalen welke shards deze moeten uitvoeren, verzendt het werk en voegt de resultaten samen in één stream. Routers kunnen verticaal en horizontaal schalen, zodat geen enkele router een bottleneck wordt.
Sharding en shard-groepen
Elke shard in Neki is echte Postgres met één primary en minstens twee replica's, verspreid over availability zones. Er is geen gemodificeerde storage engine. Extensies, SQL-ondersteuning en prestaties gedragen zich zoals Postgres dat doet, omdat het ook daadwerkelijk Postgres is.
Shards zijn georganiseerd in shard-groepen, zodat verschillende tabellen of workloads op verschillende sets shards kunnen staan. Elke shard gebruikt een configuratieprofiel dat de grootte van de instantie, het aantal replica's, de opslag, Postgres-parameters en extensies definieert, zodat je elke groep kunt afstemmen op het specifieke verkeer.
Connection pooling
Sidecars draaien naast elke Postgres-instantie. Dit onderdeel maakt het connection-beheer van Neki wezenlijk beter dan het simpelweg plaatsen van PgBouncer voor een database. Omdat Neki beide uiteinden van de verbinding beheert — de routerzijde en de Postgres-zijde — kan het de pools afstemmen op wat elke instantie daadwerkelijk kan verwerken, in plaats van dit van buiten het proces te schatten.
Control plane
De control plane houdt de gezondheid van elke node bij, voert geplande switchovers en ongeplande failovers uit, en coördineert de workflows voor het resharden van data, het toepassen van schemawijzigingen en het uitvoeren van versie-upgrades.
Datatopologie
Alles wordt samengebonden door de datatopologie: een JSON-configuratie die je logische tabellen koppelt aan fysieke shards. Je definieert shard-indexen (die bepalen op welke kolom Neki routeert en hoe die waarde wordt gehasht) en shard-groepen (die bepalen over hoeveel shards een set tabellen wordt verspreid en welke shards dat zijn). Routers cachen de topologie en raadplegen deze bij elk plan.
Wat krijg je naast sharding?
Alles waarvoor je normaal gesproken een onderhoudsvenster zou inplannen, draait in Neki als een ingebouwde workflow. Workflows voorzien nieuwe doelnodes, brengen deze bij via replicatie, schakelen het verkeer om met een __neki metafunctie en faseren de oude nodes uit. Dit gebeurt allemaal via dezelfde psql-verbinding die je applicatie gebruikt.
Dit model van online operaties omvat:
- Schemawijzigingen;
- Versie-upgrades;
- Geplande en ongeplande failovers;
- Imports;
- Resharding.
Neki bevat ook alle functies waarop je bij PlanetScale vertrouwt: Insights, schema-aanbevelingen, branching, MCP en meer.
Je kunt Neki ook ongeshard draaien, als een enkele primary met replica's. Je profiteert dan al van de verbeterde connection pooling, online DDL, upgrades zonder downtime en health monitoring, voordat sharding noodzakelijk wordt. Wanneer dat moment daar is, is resharding een workflow die je uitvoert op het cluster dat je al hebt.
Wat is een platform preview?
We wilden Neki zo snel mogelijk beschikbaar stellen. Je dient tijdens de platform preview geen productie-workloads op Neki te draaien. Het product is nog in ontwikkeling en sommige wijzigingen kunnen breaking changes zijn.
Als je feedback of vragen hebt, of problemen ervaart tijdens de platform preview, laat het ons dan weten via een supportticket of via onze Discord.
Probeer Neki vandaag nog
Log in op PlanetScale, meld je aan voor de platform preview en maak een Neki-cluster aan. Lees de Neki-documentatie voor meer informatie over de architectuur, hoe je moet sharden en meer.
Heb je een grote Postgres-cluster en ben je benieuwd of Neki een goede match is? Neem dan contact met ons op. We doen graag een privé-demo voor je team, duiken in je schema en query-patronen en geven concrete suggesties over hoe je kunt sharden.
Introductie van Neki
Neki is nu beschikbaar in platform preview.
Neki is gebouwd op basis van lessen die we hebben geleerd tijdens acht jaar het beheren van enkele van de grootste gesharde MySQL-clusters ter wereld. Duizenden productie-workloads met miljoenen queries per seconde voor bedrijven waar zelfs een paar seconden downtime een publiek incident is. We weten wat het betekent om de grootste tier 0-workloads ter wereld te ondersteunen.
Toen we anderhalf jaar geleden PlanetScale Postgres lanceerden, wisten we dat we meer moesten doen. In die tijd hebben we duizenden klanten op PlanetScale verwelkomd, waarvan sommigen qua omvang kunnen wedijveren met onze grootste MySQL-klanten. Steeds opnieuw zagen we teams tegen het plafond van een enkele machine met Postgres aanlopen. Krachtigere hardware kocht hen tijd, maar aangezien klanten de bovengrens bereikten van wat één enkele machine kan presteren, merkten we dat er geen goede optie was om hen aan te bieden. Enter Neki.
Wat is Neki?
Neki is gesharde Postgres van PlanetScale. Hiermee kun je een Postgres-database schalen over meerdere machines, terwijl er op elke shard echte Postgres blijft draaien.
Je applicatie maakt verbinding met een Neki-router via het standaard Postgres wire-protocol, zodat je bestaande drivers, ORM's en connection strings blijven werken. Elke shard is een volledig Postgres-cluster met één primary en minstens twee replica's verspreid over drie availability zones. Er is geen aangepaste storage engine, waardoor extensies, SQL-ondersteuning en prestaties zich gedragen zoals je van Postgres gewend bent.
Je kiest zelf de shard-sleutel en bepaalt hoe tabellen worden gegroepeerd en gedistribueerd via een JSON-datatopologie. Schemawijzigingen, versie-upgrades, failovers, imports en resharding worden uitgevoerd als ingebouwde, volledig online workflows. Daarnaast profiteer je van de PlanetScale-functies waarop je al vertrouwt, waaronder Insights, schema-aanbevelingen, branching en MCP.
Je hoeft niet vanaf dag één te sharden. Je kunt Neki draaien als een enkele primary met replica's. Wanneer je dan toch uitgroeit uit één machine, is resharding een workflow die je uitvoert op het cluster dat je al hebt.
Waarom Neki?
De problemen die gepaard gaan met snelgroeiende Postgres-databases zijn bekend:
- Tabellen die te groot zijn om te vacuumen of te indexeren zonder het verkeer te beïnvloeden;
- Back-ups die uren duren;
- Connectielimieten;
- Onderhoudsvensters voor schemawijzigingen;
- Transaction wraparound en meer.
Je kunt overstappen naar een grotere instantie, maar uiteindelijk raak je de beschikbare machinegrootte kwijt, en de problemen schalen niet lineair naarmate je meer cores en IOPS toevoegt.
De bestaande oplossingen vragen elk om een concessie. Sharding op applicatieniveau verplaatst de routing naar je code. Distributed databases die "Postgres-compatibel" zijn, verbergen de shard-sleutel voor je, nemen je extensies weg en voegen complexiteit en latentie toe, wat lastig te beheren en te debuggen is.
Daarom hebben we Neki gebouwd volgens een aantal principes, waarvan de belangrijkste is: houd vast aan Postgres; omzeil het niet, simuleer het niet en wijk er niet van af.
Hoe werkt Neki?
We hebben Neki vanuit eerste principes architectuurd voor Postgres, met echte Postgres op elke shard. Het systeem bestaat uit vier bewegende delen:
Neki-routers
Je applicatie maakt eerst verbinding met een Neki-router. De router spreekt het Postgres wire-protocol, zodat je bestaande drivers en ORM's blijven werken met één enkele connection string. Een router beschikt over een volledige Postgres query parser, een distributed query planner, query buffering en meer. Hij analyseert je query, stelt een plan op om te bepalen welke shards deze moeten uitvoeren, verzendt het werk en voegt de resultaten samen in één stream. Routers kunnen verticaal en horizontaal schalen, zodat geen enkele router een bottleneck wordt.
Sharding en shard-groepen
Elke shard in Neki is echte Postgres met één primary en minstens twee replica's, verspreid over availability zones. Er is geen gemodificeerde storage engine. Extensies, SQL-ondersteuning en prestaties gedragen zich zoals Postgres dat doet, omdat het ook daadwerkelijk Postgres is.
Shards zijn georganiseerd in shard-groepen, zodat verschillende tabellen of workloads op verschillende sets shards kunnen staan. Elke shard gebruikt een configuratieprofiel dat de grootte van de instantie, het aantal replica's, de opslag, Postgres-parameters en extensies definieert, zodat je elke groep kunt afstemmen op het specifieke verkeer.
Connection pooling
Sidecars draaien naast elke Postgres-instantie. Dit onderdeel maakt het connection-beheer van Neki wezenlijk beter dan het simpelweg plaatsen van PgBouncer voor een database. Omdat Neki beide uiteinden van de verbinding beheert — de routerzijde en de Postgres-zijde — kan het de pools afstemmen op wat elke instantie daadwerkelijk kan verwerken, in plaats van dit van buiten het proces te schatten.
Control plane
De control plane houdt de gezondheid van elke node bij, voert geplande switchovers en ongeplande failovers uit, en coördineert de workflows voor het resharden van data, het toepassen van schemawijzigingen en het uitvoeren van versie-upgrades.
Datatopologie
Alles wordt samengebonden door de datatopologie: een JSON-configuratie die je logische tabellen koppelt aan fysieke shards. Je definieert shard-indexen (die bepalen op welke kolom Neki routeert en hoe die waarde wordt gehasht) en shard-groepen (die bepalen over hoeveel shards een set tabellen wordt verspreid en welke shards dat zijn). Routers cachen de topologie en raadplegen deze bij elk plan.
Wat krijg je naast sharding?
Alles waarvoor je normaal gesproken een onderhoudsvenster zou inplannen, draait in Neki als een ingebouwde workflow. Workflows voorzien nieuwe doelnodes, brengen deze bij via replicatie, schakelen het verkeer om met een __neki metafunctie en faseren de oude nodes uit. Dit gebeurt allemaal via dezelfde psql-verbinding die je applicatie gebruikt.
Dit model van online operaties omvat:
- Schemawijzigingen;
- Versie-upgrades;
- Geplande en ongeplande failovers;
- Imports;
- Resharding.
Neki bevat ook alle functies waarop je bij PlanetScale vertrouwt: Insights, schema-aanbevelingen, branching, MCP en meer.
Je kunt Neki ook ongeshard draaien, als een enkele primary met replica's. Je profiteert dan al van de verbeterde connection pooling, online DDL, upgrades zonder downtime en health monitoring, voordat sharding noodzakelijk wordt. Wanneer dat moment daar is, is resharding een workflow die je uitvoert op het cluster dat je al hebt.
Wat is een platform preview?
We wilden Neki zo snel mogelijk beschikbaar stellen. Je dient tijdens de platform preview geen productie-workloads op Neki te draaien. Het product is nog in ontwikkeling en sommige wijzigingen kunnen breaking changes zijn.
Als je feedback of vragen hebt, of problemen ervaart tijdens de platform preview, laat het ons dan weten via een supportticket of via onze Discord.
Probeer Neki vandaag nog
Log in op PlanetScale, meld je aan voor de platform preview en maak een Neki-cluster aan. Lees de Neki-documentatie voor meer informatie over de architectuur, hoe je moet sharden en meer.
Heb je een grote Postgres-cluster en ben je benieuwd of Neki een goede match is? Neem dan contact met ons op. We doen graag een privé-demo voor je team, duiken in je schema en query-patronen en geven concrete suggesties over hoe je kunt sharden.
Groetjes,