Neon vs PlanetScale vs Turso: Postgres, MySQL of SQLite op de Edge?

De keuze tussen Neon, PlanetScale en Turso draait om drie fundamenteel verschillende inzetten: Postgres, MySQL/Vitess en SQLite op de edge. Het landschap is het afgelopen jaar drastisch veranderd -- Databricks kocht Neon over voor ~$1 miljard, PlanetScale lanceerde Postgres-ondersteuning, en Turso heeft scale-to-zero afgeschaft. Als je in 2026 een serverloze database kiest, is waarschijnlijk elke vergelijking die je eerder las verouderd.

Neon vs PlanetScale vs Turso in één oogopslag

Kies Neon als je volledige Postgres-compatibiliteit wilt, een genereuze gratis laag en de beste Vercel-integratie. Kies PlanetScale als je MySQL op enterprise-schaal met horizontale sharding nodig hebt. Kies Turso als edge-latentie en multi-tenant database-per-gebruiker-architecturen het belangrijkst zijn.

Dat was de korte versie. De rest van dit artikel legt precies uit waarom elke cel eruitziet zoals hij eruitziet.

Hoe werkt elke database onder de motorkap?

De engine onder elk platform bepaalt alles van querysyntaxis tot schaallimieten. Het begrijpen van de architectuur helpt je voorspellen hoe elke database zich gedraagt naarmate je app groeit.

Neon: Serverless Postgres met branching

Neon scheidt compute volledig van opslag. Je Postgres compute-knooppunten zijn efemeer -- ze starten wanneer een query binnenkomt en schalen omlaag (of naar nul) wanneer ze inactief zijn. Opslag bevindt zich op een aparte pageserver-laag die duurzaamheid en point-in-time-herstel afhandelt.

Deze architectuur maakt Neons onderscheidende functie mogelijk: copy-on-write-branching. Een databasebranch aanmaken is vrijwel direct, ongeacht de grootte, omdat er geen gegevens worden gekopieerd -- opslagpagina's worden gedeeld met de parent en er worden alleen nieuwe pagina's geschreven wanneer gegevens veranderen. Denk aan git branch voor je database.

• Volledig PostgreSQL-wire-protocol (pg_dump, psql, alles werkt)
• Autoscaling compute van 0,25 tot 56 CU
• Ingebouwde verbindingspooling via PgBouncer
• Neons architectuur gebruikt safekeepers voor write-ahead-log-duurzaamheid

PlanetScale: Vitess-aangedreven MySQL (en nu ook Postgres)

PlanetScale draait op Vitess, de MySQL-clustering-engine die oorspronkelijk bij YouTube is gebouwd om hun database over tienduizenden knooppunten te sharden. Als je horizontale schaalbaarheid voor MySQL nodig hebt, is Vitess de meest gevechtsharde oplossing die er is.

PlanetScales kenmerkende DX-functie zijn deploy requests -- in feite pull requests voor schemawijzigingen. Je stelt een migratie voor, bekijkt de diff en past die toe zonder downtime. Geen locking, geen onderhoudsvensters.

Sinds september 2025 biedt PlanetScale ook beheerde Postgres aan. Het is een ander product dan hun Vitess-aanbod -- single-node Postgres-databases vanaf €5/maand. Horizontale sharding voor Postgres (genaamd "Neki") is nog in ontwikkeling.

Voor een diepere duik wanneer Postgres meer zin maakt dan MySQL (en vice versa), bekijk onze PostgreSQL vs MySQL-vergelijking.

• Vitess: horizontale sharding, zero-downtime schemamigraties
• Postgres: single-node, productieklaar, maar nog zonder sharding
• Deploy requests voor veilige, reviewbare schemawijzigingen
• Geen scale-to-zero -- databases draaien altijd

Turso: SQLite op de edge met libSQL

Turso hanteert een heel andere aanpak. In plaats van een servergebaseerde database te draaien, gebruikt het libSQL -- een open-source fork van SQLite met server-modus-mogelijkheden. Je gegevens kunnen op de edge leven, letterlijk ingebed in de runtime van je applicatie.

Het kernprincipe zijn ingebedde replica's: lees-replica's die draaien binnen je applicatieproces (of op edge-locaties) met lezingen zonder netwerkvertraging. Schrijfbewerkingen gaan naar een primaire instantie en worden asynchroon doorgegeven aan replica's.

• libSQL breidt SQLite uit met HTTP-toegang, replicatie en multi-tenancy
• Database-per-gebruiker-model ondersteunt duizenden geïsoleerde databases
• Schrijfbewerkingen worden in milliseconden doorgegeven van primair naar replica's
• Ideaal voor lees-intensieve, wereldwijd gedistribueerde apps

Conclusie: Neon wint op architectuurbreedte. Volledige Postgres met directe branching dekt het breedste scala aan use cases. PlanetScale wint als je specifiek Vitess-grade horizontale sharding nodig hebt. Turso wint als je gegevens op de edge nodig hebt.

Hoe vergelijken ze zich qua prestaties en latentie?

Prestaties is de vraag die ontwikkelaars het eerst stellen, en het antwoord hangt volledig af van of je database warm of koud is.

Cold-start-realiteitscheck

Neon is de enige van de drie die standaard nog scale-to-zero doet. Wanneer je compute-knooppunt ontwaakt uit inactiviteit, verwacht 400–750 ms bij de eerste query. Volgende queries zijn snel. Je kunt cold starts elimineren door een minimale compute-grootte in te stellen (0,25 CU kost ongeveer €7/maand).

PlanetScale is altijd always-on geweest -- geen cold starts, punt. Je database draait, ongeacht of iemand hem bevraagt.

Turso heeft scale-to-zero voor nieuwe gebruikers afgeschaft in januari 2025. Nieuwe aanmeldingen krijgen always-on-instanties, wat geen cold starts betekent maar ook geen "betaal niets bij inactiviteit"-besparingen.

Edge-latentie: waar Turso uitblinkt

Voor warme queries zijn alle drie snel. Maar Turso's ingebedde replica's leveren iets dat de andere twee niet kunnen: lezingen in enkelvoudige milliseconden op de edge. Wanneer je SQLite-replica in dezelfde Cloudflare Worker of Vercel Edge Function als je code leeft, is er helemaal geen netwerk-hop voor lezingen.

Benchmarkgegevens van Pilcrow (juli 2023 -- als richtinggevend beschouwen, niet actueel) toonden PlanetScale HTTP op ~8 ms, Neon HTTP op ~5 ms en Turso HTTP op ~27 ms voor gecentraliseerde queries. Deze cijfers dateren van vóór PlanetScales Postgres-lancering en Turso's infrastructuurwijzigingen, dus behandel ze als referentiepunten.

Conclusie: Turso wint op edge-latentie. Ingebedde replica's met lezingen zonder netwerk-hop zijn ongeëvenaard. Voor gecentraliseerde workloads zonder cold-start-zorgen is PlanetScales always-on-consistentie moeilijk te verslaan. Neons cold starts zijn de afweging voor scale-to-zero-besparingen.

Wat kost elke database eigenlijk?

Hier schieten de meeste vergelijkingen tekort -- ze vermelden planprijzen zonder te berekenen wat een echte app zou betalen. Laten we dat oplossen.

Overzicht gratis laag

PlanetScale heeft zijn gratis Hobby-laag in april 2024 afgeschaft. Het goedkoopste instappunt is nu €5/maand voor een single-node Postgres-database. Voor Vitess/MySQL-databases is de prijsstelling clustergebaseerd en aanzienlijk hoger.

Reële maandelijkse kosten op vier schaalniveaus

Deze schattingen gebruiken actuele 2026-prijzen van de officiële prijspagina's van elk platform. Werkelijke kosten variëren per gebruikspatroon.

Een paar dingen vallen op. Turso is opmerkelijk goedkoop op de lage en middenniveaus omdat zijn rij-lezingsprijsmodel lees-intensieve apps begunstigt. Neons gebruiksgebaseerde prijsstelling betekent dat je alleen betaalt voor wat je verbruikt -- inactieve databases kosten niets op de gratis laag. PlanetScales prijsstelling is concurrerend voor Postgres single-nodes maar escaleert met Vitess-clusters.

De PlanetScale-prijsklif

PlanetScales grootste zwakte voor solo-ontwikkelaars: er is geen gratis laag. Je gaat van €0 (bij een concurrent) naar minimaal €5/maand. Voor gefinancierde startups is dit irrelevant, maar voor zijprojecten en prototyping zijn Neon en Turso's gratis lagen beduidend beter.

Aan de andere kant biedt PlanetScales Vitess-aanbod horizontale sharding die noch Neon noch Turso kan evenaren. Als je schrijfdoorvoer sharding vereist, is de premie gerechtvaardigd.

Conclusie: Neon wint voor de meeste budgetten. De gratis laag plus gebruiksgebaseerde prijsstelling is het meest flexibele model. Turso's rij-lezingsprijsstelling is uitstekend voor lees-intensieve apps. PlanetScale kost meer aan het lage einde maar levert enterprise-grade schaalbaarheid.

Hoe is de ontwikkelaarservaring?

Dagelijkse DX is belangrijker dan benchmarkcijfers. Zo vergelijken de drie op de functies die je daadwerkelijk zult gebruiken.

Database-branching en CI/CD

Neons copy-on-write-branching is de gouden standaard. Maak een branch aan voor elke PR, voer migraties ertegenaan uit, test met productieachtige gegevens en merge. De Vercel-integratie maakt automatisch een branch aan per preview-deployment.

PlanetScales deploy requests zijn een andere variant van hetzelfde idee. In plaats van de hele database te branchen, branch je het schema. Stel een migratie voor, bekijk de diff en pas die toe zonder downtime. Het is eigenzinniger maar aantoonbaar veiliger voor schemawijzigingen op schaal.

Turso heeft geen branching. Je beheert migraties met standaard SQLite-tooling.

ORM-compatibiliteitsmatrix

Neon en PlanetScales Postgres-aanbod werken direct met het volledige Postgres-ORM-ecosysteem. Turso vereist libSQL-specifieke adapters, die goed worden onderhouden maar beperkter zijn.

CLI en lokale ontwikkeling

Alle drie hebben solide CLI's: neonctl voor Neon, pscale voor PlanetScale en turso voor Turso. Elk ondersteunt het aanmaken van databases, het beheren van branches (waar van toepassing) en verbinding maken vanuit je terminal.

Voor lokale ontwikkeling blinken Neon-branches uit -- je kunt ontwikkelen tegen een branch die productiegegevens weerspiegelt zonder de productie aan te raken. PlanetScales development-branches dienen een vergelijkbaar doel. Turso draait SQLite lokaal, dus lokale ontwikkeling is heel eenvoudig -- wijs gewoon naar een lokaal .db-bestand.

Conclusie: Neon wint op ontwikkelaarservaring. Copy-on-write-branching met Vercel-integratie is het beste CI/CD-verhaal. PlanetScales deploy requests zijn uitstekend voor teams die schema-niveau-review willen. Turso's eenvoud is onderschat maar mist branching.

Verbinding maken vanuit Next.js -- side-by-side code

Zo ziet het er uit om verbinding te maken met elke database vanuit een Next.js API-route of Server Component. Deze zijn klaar om te kopiëren en plakken.

Raw driver-verbinding (alle drie)

Neon met @neondatabase/serverless:

// lib/neon.ts
import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);

// Werkt in Edge Runtime en Node.js
export async function getActiveUsers() {
  const users = await sql`
    SELECT * FROM users WHERE active = true
  `;
  return users;
}

PlanetScale met @planetscale/database:

// lib/planetscale.ts
import { connect } from "@planetscale/database";

const conn = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});

// Werkt in Edge Runtime en Node.js
export async function getActiveUsers() {
  const results = await conn.execute(
    "SELECT * FROM users WHERE active = true"
  );
  return results.rows;
}

Turso met @libsql/client:

// lib/turso.ts
import { createClient } from "@libsql/client";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Werkt in Edge Runtime en Node.js
export async function getActiveUsers() {
  const result = await turso.execute(
    "SELECT * FROM users WHERE active = 1"
  );
  return result.rows;
}

Merk op dat Turso = 1 gebruikt in plaats van = true -- SQLite heeft geen native boolean-type. Klein verschil, maar het overvalt mensen.

Drizzle ORM-setup (alle drie)

Als je Drizzle gebruikt (en dat zou je waarschijnlijk moeten voor type-safe queries), hier is de configuratie voor elke database:

// drizzle.config.ts — Neon
import { neon } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-http";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);

// drizzle.config.ts — PlanetScale (MySQL/Vitess)
import { connect } from "@planetscale/database";
import { drizzle } from "drizzle-orm/planetscale-serverless";

const connection = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});
export const db = drizzle(connection);

// drizzle.config.ts — Turso
import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});
export const db = drizzle(turso);

Alle drie drivers werken in Vercel Edge Functions en Cloudflare Workers. Het API-oppervlak is gelijkaardig genoeg dat wisselen tussen hen grotendeels een driver-wissel is -- je Drizzle-schema en queries blijven hetzelfde (minus SQL-dialectverschillen).

Kun je meerdere serverloze databases samen gebruiken?

Hier is een patroon dat tractie wint in de community maar geen enkel vergelijkingsartikel bespreekt: Turso gebruiken voor edge-lezingen en Neon voor schrijfbewerkingen.

Het idee is eenvoudig. Je primaire gegevens leven in Neon (volledige Postgres, sterke consistentie, rijke queryondersteuning). Je repliceert lees-intensieve gegevens naar Turso edge-replica's die wereldwijd dicht bij je gebruikers staan. Lezingen raken Turso met sub-milliseconde latentie; schrijfbewerkingen gaan naar Neon voor duurzaamheid en consistentie.

Wanneer dit zinvol is:

• Wereldwijd gedistribueerde apps waar leeslatentie belangrijk is (dashboards, contentplatforms)
• Multi-tenant SaaS waarbij de lees-intensieve gegevens van elke tenant profiteren van edge-caching
• Apps met een 90/10 lees/schrijf-verhouding waarbij je iets verouderde lezingen kunt tolereren

Wanneer je het overslaat:

• De meeste apps hebben geen sub-10 ms globale lezingen nodig -- een single-regio Neon-instantie is prima
• De complexiteit van het onderhouden van twee databases, synchroniseren van gegevens en afhandelen van storingen is reëel
• Als je app schrijf-intensief is, helpen edge-lezingen niet veel

Wees eerlijk met jezelf: als je niet op wereldwijde schaal opereert met strikte latentievereisten, voegt dit complexiteit toe zonder zinvol voordeel. Maar voor de apps die het nodig hebben, is het een echt elegant patroon.

Wat is er veranderd in 2025–2026? (De drie grote omslagen)

Elke concurrentievergelijking is geschreven vóór deze gebeurtenissen. Dit is wat er veranderd is en wat het vandaag voor jouw beslissing betekent.

Neon + Databricks: wat de overname van $1 miljard betekent

In mei 2025 kocht Databricks Neon over voor ongeveer $1 miljard. Dit was niet alleen een financiële gebeurtenis -- het veranderde Neons koers.

De directe impact: Neon verlaagde de opslagkosten met 80% (van $1,75 naar $0,35 per GB-maand). De Vantage-analyse suggereert dat dit deels komt van Databricks' AWS-volumekortingen die doorwerken naar Neon-klanten.

Het strategische signaal: Databricks merkte op dat 80% van de Neon-databases nu worden aangemaakt door AI-agenten, tegenover 30% bij GA. Neon positioneert zich als de standaarddatabase voor AI-gestuurde ontwikkeling -- geautomatiseerde schemaopbouw, door agenten beheerde gegevens, programmatische database-inrichting.

Voor jou als ontwikkelaar betekent de overname: goedkopere prijzen, enterprise-backing (Databricks is winstgevend) en een roadmap die steeds meer geoptimaliseerd is voor programmatische/AI-workflows.

PlanetScale Postgres: MySQL is niet langer de enige optie

In september 2025 lanceerde PlanetScale Postgres-ondersteuning als GA. Dit verandert het oude "Neon = Postgres, PlanetScale = MySQL"-kader volledig.

PlanetScale Postgres begint bij €5/maand voor single-node databases met functies zoals Query Insights, schema-aanbevelingen en branching. Het is productieklaar en draait al bij honderden bedrijven. Horizontale sharding voor Postgres (hun "Neki"-project) is echter nog in ontwikkeling.

Wat dit betekent: als je kiest tussen Neon vs PlanetScale puur op engine-voorkeur, dekt PlanetScale nu beide. Maar Neons Postgres is volwassener (het is vanaf dag één Postgres-native), heeft een gratis laag en biedt diepere branching met copy-on-write-semantiek. PlanetScale Postgres is het waard om in de gaten te houden, maar Neon leidt nog steeds aan de Postgres-kant.

Turso schrapt scale-to-zero: always-on als standaard

In januari 2025 kondigde Turso significante platformwijzigingen aan: scale-to-zero afgeschaft voor nieuwe gebruikers, infrastructuurconsolidatie naar AWS, en edge-replica's stopgezet voor nieuwe aanmeldingen.

De afweging is duidelijk: geen cold starts meer (goed), maar ook geen "gratis bij inactiviteit"-besparingen meer (minder goed). Bestaande gebruikers met legacy-plannen behouden scale-to-zero, maar alle anderen krijgen always-on-instanties.

Dit maakt Turso voorspelbaarder -- je wordt niet verrast door cold-start-latentie -- maar het verkleint ook de kloof tussen Turso en PlanetScale op de "serverless"-dimensie. Beide zijn nu always-on beheerde databases; Turso's edge-verhaal is wat het onderscheidt.

Neon vs PlanetScale vs Turso: welke moet je kiezen?

Genoeg analyse. Hier is het beslissingskader.

Voor de meeste ontwikkelaars die in 2026 een nieuw project starten, is Neon de standaardkeuze. Gratis laag, volledige Postgres, directe branching en Vercel-integratie dekken 80% van de use cases. Je kunt altijd opschalen naar betaalde plannen of later wisselen -- het Postgres-ecosysteem betekent dat je nooit vastzit.

PlanetScale verdient zijn plaats wanneer je MySQL op enterprise-schaal nodig hebt of de deploy request-workflow wilt voor zero-downtime schemawijzigingen in grote teams.

Turso is de juiste keuze wanneer je architectuur edge-first gegevenstoegang of multi-tenant database-isolatie op schaal vereist. Het is een gespecialiseerd hulpmiddel, en het is uitstekend in waar het in gespecialiseerd is.

Hoe Techsy de selectie van serverloze databases aanpakt

We evalueren serverloze databases op vier dimensies voor elk klantproject: complexiteit van het datamodel, teamgrootte en SQL-dialectvoorkeur, schaaltraject over de komende 12–18 maanden, en deploymentplatform (Vercel, Cloudflare, AWS, etc.).

Onze standaardstack voor de meeste projecten is Neon + Drizzle + Next.js. Dit is waarom:

1. Postgres geeft ons het rijkste ecosysteem -- JSON-kolommen, volledige-tekstzoekopdrachten, PostGIS, extensies
2. Neons branching past perfect bij preview-deployments en CI-pipelines
3. De gratis laag laat ons prototypen zonder facturatieoverhead voor early-stage klanten
4. Drizzle's type safety detecteert schema-drift voordat het de productie raakt

Wanneer we alternatieven aanbevelen:

• PlanetScale voor teams die migreren vanuit bestaande MySQL-infrastructuur waarbij het herschrijven van queries niet praktisch is
• Turso voor klanten die wereldwijd gedistribueerde, lees-intensieve producten bouwen waarbij edge-latentie een meetbare bedrijfsmaatstaf is
• Soms is het eerlijke antwoord "gebruik gewoon Supabase" wanneer je auth + database + opslag in één beheerd pakket nodig hebt

Hulp nodig bij het kiezen van de juiste database voor je volgende project? Krijg een gratis backend-consultatie.

FAQ

Is Neon beter dan PlanetScale?

Dat hangt van je behoeften af. Neon is beter voor Postgres-native teams, biedt een gratis laag en heeft diepere database-branching met copy-on-write-semantiek. PlanetScale is beter voor MySQL-workloads op enterprise-schaal met Vitess-sharding en zero-downtime deploy requests. Omdat PlanetScale nu ook Postgres aanbiedt, wordt de kloof kleiner -- maar Neons Postgres is volwassener.

Wat is het verschil tussen Neon en Turso?

Neon is serverless PostgreSQL met compute-opslagscheiding en directe branching. Turso is SQLite-gebaseerd (libSQL) met ingebedde replica's voor edge-lezingen. Kies Neon voor het volledige Postgres-ecosysteem en branching-workflows. Kies Turso voor globale lage-latentielezingen en multi-tenant database-per-gebruiker-architecturen.

Is PlanetScale zonder gratis laag nog de moeite waard?

Voor hobbyprojecten waarschijnlijk niet -- Neon en Turso bieden beide genereuze gratis lagen. Voor gefinancierde startups en ondernemingen die Vitess-aangedreven horizontale sharding of zero-downtime deploy requests nodig hebben, is PlanetScales prijsstelling gerechtvaardigd. Het €5/maand Postgres-instappunt is concurrerend, maar niet gratis.

Wat is de beste serverloze database voor Next.js?

Neon, voor de meeste ontwikkelaars. Het heeft de diepste Vercel-integratie (branch per preview-deployment), werkt met alle Postgres-ORM's en begint gratis. Turso is de keuze als je specifiek globale edge-lezingen nodig hebt. Alle drie hebben drivers die werken in Vercel Edge Functions.

Hoe erg zijn Neon cold starts in productie?

Verwacht 400–750 ms bij de eerste query wanneer compute ontwaakt uit inactiviteit. Volgende queries zijn snel (enkelvoudige ms). Voor altijd-responsieve apps, stel het minimum compute in op 0,25 CU (ongeveer €7/maand op het Launch-plan) om de instantie warm te houden en cold starts volledig te elimineren.

Kan PlanetScale nu PostgreSQL gebruiken?

Ja, sinds september 2025. PlanetScale lanceerde PostgreSQL-ondersteuning als GA, met single-node databases vanaf €5/maand. Het is productieklaar met honderden bedrijven die erop draaien. Horizontale sharding voor Postgres is echter nog in ontwikkeling -- daarvoor heb je hun Vitess/MySQL-aanbod nodig.

Is Turso goed voor productie-apps?

Ja, met voorbehoud. Turso blinkt uit bij lees-intensieve workloads en multi-tenant-architecturen. Schrijf-concurrentie is aanzienlijk verbeterd. Het is het meest geschikt voor apps met hoge lees-schrijf-verhoudingen en vereisten voor wereldwijde distributie. Voor schrijf-intensieve transactionele workloads zijn Neon of PlanetScale betere keuzes.

Wat is er gebeurd met PlanetScales gratis laag?

PlanetScale verwijderde zijn Hobby (gratis) laag in april 2024. Nieuwe Hobby-databases werden geblokkeerd op 6 maart 2024, en alle bestaande werden op 8 april 2024 stopgezet. Het goedkoopste instappunt is nu €5/maand voor een Postgres single-node database. Dit dreef veel solo-ontwikkelaars ertoe te migreren naar Neon of Turso.

Hoe beïnvloedt de Databricks-overname Neon?

Databricks kocht Neon over voor ~$1 miljard in mei 2025. Sindsdien heeft Neon de opslagkosten met 80% verlaagd, geïnvesteerd in AI-agent-workflows en enterprise-geloofwaardigheid gewonnen. Prijzen zijn goedkoper geworden, niet duurder. De overname signaleert langetermijnstabiliteit -- Databricks is winstgevend en toegewijd aan Neon als zijn Postgres-laag.

Ondersteunt Turso nog steeds scale-to-zero?

Turso heeft scale-to-zero voor nieuwe gebruikers begin 2025 afgeschaft. Bestaande gebruikers met legacy-plannen behouden het, maar nieuwe aanmeldingen krijgen always-on-instanties. Dit elimineert cold starts maar verwijdert het "betaal niets bij inactiviteit"-voordeel. Edge-replica's werden ook stopgezet voor nieuwe gebruikers als onderdeel van de platformconsolidatie.

Welke serverloze database is het goedkoopst voor een zijproject?

Neon en Turso bieden beide gratis lagen die de meeste zijprojecten aankunnen. Neon geeft je 0,5 GB opslag en 100 compute-uren. Turso geeft je 5 GB opslag en 500 miljoen rij-lezingen. PlanetScale heeft geen gratis laag -- het minimum is €5/maand. Voor een typisch zijproject met licht verkeer is elke gratis laag meer dan genoeg.

Eindconclusie

Voor de meeste ontwikkelaars in 2026 is Neon de beste serverloze database om mee te starten. Het geeft je het volledige Postgres-ecosysteem, een gratis laag die echt werkt voor echte projecten, directe branching voor CI/CD en prijsstelling die meegroeit met gebruik. De Databricks-backing voegt enterprise-stabiliteit toe zonder enterprise-lock-in.

PlanetScale verdient zijn plaats wanneer je horizontale MySQL-sharding nodig hebt of je team al geïnvesteerd is in het MySQL-ecosysteem. Turso is de juiste keuze wanneer edge-latentie een meetbare vereiste is, niet alleen een nice-to-have.

Beoordeel je datamodel, je schaaltraject en waar je gebruikers zijn. Kies dan één en begin te bouwen -- alle drie zijn productieklaar, en de Postgres/MySQL/SQLite-ecosystemen betekenen dat je nooit echt vastzit.

Bronnen

• Neon Architectuuroverzicht
• Neon Prijzen
• PlanetScale Prijzen
• PlanetScale voor Postgres is nu GA
• Turso Prijzen
• Turso libSQL Documentatie
• Databricks stemt in met overname van Neon
• Aankomende wijzigingen aan het Turso-platform
• PlanetScale schrapt het Hobby-plan
• Serverless Database Latency Benchmarks -- Pilcrow (2023)
• Drizzle ORM -- Turso verbinden