Neon vs PlanetScale vs Turso: Postgres, MySQL eller SQLite ved kanten?

Beslutningen om Neon vs PlanetScale vs Turso koges ned til tre fundamentalt forskellige valg: Postgres, MySQL/Vitess og SQLite ved kanten (edge). Landskabet har ændret sig dramatisk over det sidste år: Databricks opkøbte Neon for ~1 mia. USD, PlanetScale lancerede understøttelse af Postgres, og Turso udfasede scale-to-zero. Hvis du vælger en serverless database i 2026, er hver eneste sammenligning, du har læst, sandsynligvis forældet.

Neon vs PlanetScale vs Turso ved første øjekast

Vælg Neon, hvis du ønsker fuld Postgres-kompatibilitet, en generøs gratisplan og den bedste Vercel-integration. Vælg PlanetScale, hvis du har brug for MySQL i enterpriseskala med horisontal sharding. Vælg Turso, hvis lav latenstid ved kanten og multi-tenant arkitekturer med én database pr. bruger betyder mest.

Det er hurtigversionen. Resten af denne artikel gennemgår præcis, hvorfor hver celle ser ud, som den gør.

Hvordan fungerer hver database under motorhjelmen?

Motoren bag hver platform former alt fra query-syntaks til skaleringsgrænser. At forstå arkitekturen hjælper dig med at forudsige, hvordan hver database vil opføre sig, efterhånden som din app vokser.

Neon: Serverless Postgres med grening

Neon adskiller beregning (compute) og lagring fuldstændigt. Dine Postgres-compute-noder er flygtige; de starter op, når en query ankommer, og skalerer ned (eller til nul), når de er inaktive. Lagringen ligger på et separat pageserver-lag, der håndterer holdbarhed og point-in-time recovery.

Denne arkitektur muliggør Neons killer-feature: copy-on-write-grening. Oprettelse af en databasegren sker næsten øjeblikkeligt uanset størrelse, fordi den ikke kopierer data; den deler lagringssider med forælderen og skriver kun nye sider, når data ændres. Tænk på det som git branch til din database.

• Fuld PostgreSQL wire-protokol (pg_dump, psql, alt virker)
• Autoskalering af compute fra 0,25 til 56 CU
• Indbygget connection pooling via PgBouncer
• Neons arkitektur bruger safekeepers til write-ahead log-holdbarhed

PlanetScale: Vitess-drevet MySQL (og nu Postgres)

PlanetScale kører på Vitess, MySQL-clustering-motoren, der oprindeligt blev bygget hos YouTube for at shard'e deres database på tværs af titusindvis af noder. Hvis du har brug for horisontal skalering til MySQL, er Vitess den mest battle-tested løsning, der findes.

PlanetScales signatur-DX-feature er deploy-anmodninger, dybest set pull requests til schema-ændringer. Du foreslår en migration, gennemgår diff'en og anvender den uden nedetid. Ingen låsning, ingen vedligeholdelsesvinduer.

Siden september 2025 har PlanetScale også tilbudt managed Postgres. Det er et andet produkt end deres Vitess-tilbud: single-node Postgres-databaser starter ved $5/md. Horisontal sharding til Postgres (kaldet "Neki") er stadig under udvikling.

For et dybere dyk i, hvornår Postgres giver mere mening end MySQL (og omvendt), kan du tjekke vores PostgreSQL vs MySQL-sammenligning.

• Vitess: horisontal sharding, schema-migrationer uden nedetid
• Postgres: single-node, produktionsklar, men uden sharding endnu
• Deploy-anmodninger til sikre, gennemgåelige schema-ændringer
• Ingen scale-to-zero, databaser kører altid

Turso: SQLite ved kanten med libSQL

Turso tager en helt anden tilgang. I stedet for at køre en serverbaseret database bruger den libSQL, en open source-fork af SQLite med server-mode-funktioner. Dine data kan leve ved kanten, bogstaveligt talt indlejret i din applikations runtime.

Kernekonceptet er indlejrede replikater: læsereplikater, der kører inde i din applikationsproces (eller på edge-lokationer) med læsninger uden netværkslatens. Skrivninger går til en primær instans og propageres asynkront til replikaterne.

• libSQL udvider SQLite med HTTP-adgang, replikering og multi-tenancy
• Database-per-bruger-modellen understøtter tusindvis af isolerede databaser
• Skrivninger propageres fra primær til replikater på millisekunder
• Ideel til læsetunge, globalt distribuerede apps

Dom: Neon vinder på arkitekturbredde. Fuld Postgres med øjeblikkelig grening dækker det bredeste udvalg af use cases. PlanetScale vinder, hvis du specifikt har brug for Vitess-grade horisontal sharding. Turso vinder, hvis du har brug for data ved kanten.

Hvordan sammenligner de sig på ydeevne og latenstid?

Ydeevne er det spørgsmål, udviklere stiller først, og svaret afhænger helt af, om din database er "warm" eller "cold".

Virkelighedstjek på cold starts

Neon er den eneste af de tre, der stadig udfører scale-to-zero som standard. Når din compute-node vågner fra inaktivitet, skal du forvente 400-750 ms på den første query. Efterfølgende queries er hurtige. Du kan eliminere cold starts ved at indstille en minimumsstørrelse for compute (0,25 CU koster cirka $7/md.).

PlanetScale har altid været always-on, ingen cold starts, punktum. Din database kører, uanset om nogen query'er den eller ej.

Turso udfasede scale-to-zero for nye brugere i januar 2025. Nye tilmeldinger får always-on-instanser, hvilket betyder ingen cold starts, men heller ingen "betal intet, når inaktiv"-besparelser.

Edge-latenstid: Hvor Turso skinner

For varme queries er alle tre hurtige. Men Tursos indlejrede replikater leverer noget, de to andre ikke kan: læsninger i enkelt-cifrede millisekunder ved kanten. Når din SQLite-replikat lever i samme Cloudflare Worker eller Vercel Edge Function som din kode, er der slet ingen netværkshop for læsninger.

Benchmark-data fra Pilcrow (juli 2023 -- behandles som retningsgivende, ikke aktuelt) viste PlanetScale HTTP på ~8 ms, Neon HTTP på ~5 ms og Turso HTTP på ~27 ms for centraliserede queries. Uafhængige benchmarks på Cloudflare Workers bekræftede lignende mønstre. Disse tal stammer fra før PlanetScales Postgres-lancering og Tursos infrastrukturændringer, så tag dem som referencepunkter snarere end sandhed med store bogstaver.

Dom: Turso vinder på edge-latenstid. Indlejrede replikater med læsninger uden netværkshop er uovertrufne. Til centraliserede arbejdsbyrder uden bekymring for cold starts er PlanetScales always-on-konsistens svær at slå. Neons cold starts er tradeoff'en for scale-to-zero-besparelser.

Hvad koster hver database egentlig?

Her falder de fleste sammenligninger fra hinanden; de lister planpriser uden at beregne, hvad en rigtig app ville betale. Lad os rette op på det.

Opsummering af gratisplaner

PlanetScale fjernede sin gratis Hobby-plan i april 2024. Det billigste indgangspunkt er nu $5/md. for en single-node Postgres-database. For Vitess/MySQL-databaser er prissætningen cluster-baseret og betydeligt højere.

Reelle månedlige omkostninger ved fire skaleringsniveauer

Disse estimater bruger nuværende 2026-priser fra hver platforms officielle prissider. Faktiske omkostninger varierer efter brugsmønstre.

Noget springer i øjnene. Turso er bemærkelsesværdigt billigt i de lave og mellemste niveauer, fordi dens rækkelæsnings-prismodel favoriserer læsetunge apps. Neons forbrugsbaserede prissætning betyder, at du kun betaler for det, du bruger; inaktive databaser koster intet på gratisplanen. PlanetScales prissætning er konkurrencedygtig for Postgres single-nodes, men stiger med Vitess-clustre.

PlanetScales prisklippe

PlanetScales største svaghed for solo-udviklere: der er ingen gratisplan. Du går fra $0 (ved at bruge en konkurrent) til mindst $5/md. For finansierede startups er dette irrelevant, men til sideprojekter og prototyping er Neons og Tursos gratisplaner meningsfuldt bedre.

På den anden side giver PlanetScales Vitess-tilbud horisontal sharding, som hverken Neon eller Turso kan matche. Hvis dit skrive-throughput kræver sharding, er premium-prisen berettiget.

Dom: Neon vinder for de fleste budgetter. Gratisplanen plus forbrugsbaseret prissætning er den mest fleksible model. Tursos rækkelæsnings-prissætning er fremragende til læsetunge apps. PlanetScale koster mere i den lave ende, men leverer enterpriseskalering.

Hvordan er developer experience (DX)?

Dag-til-dag DX betyder mere end benchmark-tal. Her er hvordan de tre sammenligner sig på de funktioner, du rent faktisk vil bruge.

Database-grening og CI/CD

Neons copy-on-write-grening er guldstandarden. Opret en gren til hver PR, kør migrationer mod den, test med produktionslignende data, og merg. Vercel-integrationen opretter automatisk en gren pr. preview-deployment.

PlanetScales deploy-anmodninger er en anden smag af samme idé. I stedet for at grene hele databasen, grener du schema'et. Foreslå en migration, gennemgå diff'en, og anvend den uden nedetid. Det er mere opinionated, men måske sikrere til schema-ændringer i stor skala.

Turso har ikke grening. Du administrerer migrationer med standard SQLite-værktøjer.

ORM-kompatibilitetsmatrix

Neon og PlanetScales Postgres-tilbud fungerer med hele Postgres ORM-økosystemet out of the box. Turso kræver libSQL-specifikke adapters, som er velvedligeholdt, men snævrere.

CLI og lokal udvikling

Alle tre har solide CLIs: neonctl til Neon, pscale til PlanetScale og turso til Turso. Hver understøtter oprettelse af databaser, administration af grene (hvor relevant) og forbindelse fra din terminal.

Til lokal udvikling skinner Neon-grene; du kan udvikle mod en gren, der spejler produktionsdata uden at røre produktionen. PlanetScales udviklingsgrene tjener et lignende formål. Turso kører SQLite lokalt, så lokal dev er dødsimpel; peg bare på en lokal .db-fil.

Dom: Neon vinder på developer experience. Copy-on-write-grening med Vercel-integration er den bedste CI/CD-historie. PlanetScales deploy-anmodninger er fremragende til teams, der ønsker review på schema-niveau. Tursos enkelthed er undervurderet, men mangler grening.

Forbindelse fra Next.js, side-om-side kode

Her er hvordan det ser ud at forbinde til hver database fra en Next.js API-rute eller Server Component. Disse er klar til copy-paste.

Raw driver-forbindelse (alle tre)

Neon med @neondatabase/serverless:

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

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

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

PlanetScale med @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,
});

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

Turso med @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,
});

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

Bemærk, at Turso bruger = 1 i stedet for = true; SQLite har ikke en native boolean-type. Lille forskel, men det fanger folk uforberedt.

Drizzle ORM-setup (alle tre)

Hvis du bruger Drizzle (og det bør du nok for type-sikre queries), her er konfigurationen for hver:

// 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 tre drivere fungerer i Vercel Edge Functions og Cloudflare Workers. API-overfladen er lignende nok til, at skift mellem dem mest er et driverskift; dit Drizzle-schema og dine queries forbliver de samme (minus SQL-dialektforskelle).

Kan du bruge flere serverless databaser sammen?

Her er et mønster, der vinder frem i community'et, men som ingen sammenligningsartikler taler om: brug af Turso til edge-læsninger og Neon til skrivninger.

Idéen er ligetil. Dine primære data lever i Neon (fuld Postgres, stærk konsistens, rig query-support). Du replikerer læsetunge data til Turso edge-replikater, der sidder tæt på dine brugere globalt. Læsninger rammer Turso med sub-millisekund latenstid; skrivninger går til Neon for holdbarhed og konsistens.

Når dette giver mening:

• Globalt distribuerede apps, hvor læselatenstid betyder noget (dashboards, content-platforme)
• Multi-tenant SaaS, hvor hver tenants læsetunge data drager fordel af edge-caching
• Apps med et 90/10 læse/skrive-forhold, hvor du kan tolerere lidt forældede læsninger

Når du skal springe det over:

• De fleste apps behøver ikke sub-10 ms globale læsninger; en single-region Neon-instans er fin
• Kompleksiteten ved at vedligeholde to databaser, synkronisere data og håndtere fejl er reel
• Hvis din app er skriveintensiv, hjælper edge-læsninger ikke meget

Vær ærlig over for dig selv: hvis du ikke opererer i global skala med strenge latenstidskrav, tilføjer dette kompleksitet uden meningsfuld gevinst. Men for de apps, der har brug for det, er det et genuint elegant mønster.

Hvad ændrede sig i 2025-2026? (De tre store omvæltninger)

Hver konkurrentsammenligning blev skrevet før disse begivenheder. Her er hvad der ændrede sig, og hvad det betyder for din beslutning i dag.

Neon + Databricks: Hvad $1 mia.-opkøbet betyder

I maj 2025 opkøbte Databricks Neon for ca. 1 milliard dollar. Dette var ikke bare en finansiel begivenhed; det ændrede Neons kurs.

Den umiddelbare effekt: Neon skar lageromkostningerne med 80% (fra $1,75 til $0,35 per GB-måned). Vantage-analysen antyder, at dette delvist kom fra Databricks' AWS-volumenrabatter, der flød videre til Neon-kunder.

Det strategiske signal: Databricks citerede, at 80% af Neon-databaser nu oprettes af AI-agenter, op fra 30% ved GA. Neon positionerer sig som standarddatabasen til AI-drevet udvikling, automatiseret schema-oprettelse, agent-administrerede data og programmatisk database-provisioning.

For dig som udvikler betyder opkøbet: billigere priser, enterprise-backing (Databricks er profitabelt) og en roadmap, der i stigende grad er optimeret til programmatiske/AI-workflows.

PlanetScale Postgres: MySQL er ikke længere den eneste mulighed

I september 2025 lancerede PlanetScale Postgres-support som GA. Dette ændrer fuldstændigt den gamle "Neon = Postgres, PlanetScale = MySQL"-ramme.

PlanetScale Postgres starter ved $5/md. for single-node-databaser med funktioner som Query Insights, schema-anbefalinger og grening. Det er produktionsklart og kører allerede hos hundredvis af virksomheder. Horisontal sharding til Postgres (deres "Neki"-projekt) er dog stadig under udvikling.

Hvad dette betyder: hvis du vælger mellem Neon vs PlanetScale udelukkende baseret på engine-præference, dækker PlanetScale nu begge. Men Neons Postgres er mere modent (det har været Postgres-native fra dag ét), har en gratisplan og tilbyder dybere grening med copy-on-write-semantik. PlanetScale Postgres er værd at holde øje med, men Neon fører stadig på Postgres-siden.

Turso dropper scale-to-zero: Always-on som standard

I januar 2025 annoncerede Turso betydelige platformændringer: scale-to-zero udfaset for nye brugere, infrastrukturkonsolidering til AWS og edge-replikater indstillet for nye tilmeldinger.

Tradeoff'en er klar: ingen flere cold starts (godt), men ingen flere "gratis når inaktiv"-besparelser (knapt så godt). Eksisterende brugere på legacy-planer beholder scale-to-zero, men alle andre får always-on-instanser.

Dette gør Turso mere forudsigelig; du bliver ikke overrasket af cold start-latenstid, men det indsnævrer også kløften mellem Turso og PlanetScale på "serverless"-dimensionen. Begge er nu always-on managed databaser; Tursos edge-historie er det, der differentierer den.

Neon vs PlanetScale vs Turso: Hvilken skal du vælge?

Nok analyse. Her er beslutningsframework'et.

For de fleste udviklere, der starter et nyt projekt i 2026, er Neon det standardvalg. Gratisplan, fuld Postgres, øjeblikkelig grening og Vercel-integration dækker 80% af use cases. Du kan altid skalere op til de betalte planer eller skifte senere; Postgres-økosystemet betyder, at du aldrig er låst fast.

PlanetScale fortjener sin plads, når du har brug for MySQL i enterpriseskala, eller ønsker deploy-anmodnings-workflowet til schema-ændringer uden nedetid på tværs af store teams.

Turso er det rigtige valg, når din arkitektur kræver edge-first dataadgang eller multi-tenant database-isolering i stor skala. Det er et specialiseret værktøj, og det er fremragende til det, det specialiserer sig i.

Hvordan Techsy tilgår valg af serverless database

Vi evaluerer serverless databaser på fire dimensioner for hvert klientprojekt: datamodelkompleksitet, teamstørrelse og SQL-dialektpræference, skaleringsbane over de næste 12-18 måneder og deploymentsplatform (Vercel, Cloudflare, AWS osv.).

Vores default-stack til de fleste projekter er Neon + Drizzle + Next.js. Her er hvorfor:

1. Postgres giver os det rigeste økosystem: JSON-kolonner, full-text search, PostGIS, extensions
2. Neons grening mapper perfekt til preview-deployments og CI-pipelines
3. Gratisplanen lader os prototype uden billing-overhead for tidlige klienter
4. Drizzles typesikkerhed fanger schema-drift, før det rammer produktion

Når vi anbefaler alternativer:

• PlanetScale til teams, der migrerer fra eksisterende MySQL-infrastruktur, hvor omskrivning af queries ikke er praktisk
• Turso til klienter, der bygger globalt distribuerede, læsetunge produkter, hvor edge-latenstid er en målebar business-metrik
• Nogle gange er det ærlige svar "brug bare Supabase", når det, du har brug for, er auth + database + storage i én managed pakke

Har du brug for hjælp til at vælge den rigtige database til dit næste projekt? Få en gratis backend-konsultation.

FAQ

Er Neon bedre end PlanetScale?

Det afhænger af dine behov. Neon er bedre til Postgres-native teams, tilbyder en gratisplan og har dybere database-grening med copy-on-write-semantik. PlanetScale er bedre til MySQL-workloads i enterpriseskala med Vitess-sharding og deploy-anmodninger uden nedetid. Da PlanetScale nu også tilbyder Postgres, indsnævres kløften, men Neons Postgres er mere modent.

Hvad er forskellen mellem Neon og Turso?

Neon er serverless PostgreSQL med adskillelse af compute og lagring samt øjeblikkelig grening. Turso er SQLite-baseret (libSQL) med indlejrede replikater til edge-læsninger. Vælg Neon til det fulde Postgres-økosystem og grening-workflows. Vælg Turso til globale lav-latens læsninger og multi-tenant arkitekturer med én database pr. bruger.

Er PlanetScale stadig det værd uden en gratisplan?

Til hobbyprojekter, sandsynligvis ikke; både Neon og Turso tilbyder generøse gratisplaner. Til finansierede startups og enterprises, der har brug for Vitess-drevet horisontal sharding eller deploy-anmodninger uden nedetid, er PlanetScales prissætning berettiget. $5/md. indgangspunktet for Postgres er konkurrencedygtigt, dog ikke gratis.

Hvad er den bedste serverless database til Next.js?

Neon, for de fleste udviklere. Den har den dybeste Vercel-integration (gren pr. preview-deployment), fungerer med alle Postgres ORMs og starter gratis. Turso er valget, hvis du specifikt har brug for globale edge-læsninger. Alle tre har drivere, der fungerer i Vercel Edge Functions.

Hvor slemt er Neons cold starts i produktion?

Forvent 400-750 ms på den første query, når compute vågner fra nul. Efterfølgende queries er hurtige (enkelt-cifrede ms). Til apps, der skal være altid responsive, skal du indstille minimum compute til 0,25 CU (ca. $7/md. på Launch-planen) for at holde instansen warm og eliminere cold starts helt.

Kan PlanetScale bruge PostgreSQL nu?

Ja, siden september 2025. PlanetScale lancerede PostgreSQL-support som GA med single-node-databaser startende ved $5/md. Det er produktionsklart med hundredvis af virksomheder, der kører på det. Horisontal sharding til Postgres er dog stadig under udvikling; til det skal du bruge deres Vitess/MySQL-tilbud.

Er Turso godt til produktionsapps?

Ja, med forbehold. Turso excellerer ved læsetunge workloads og multi-tenant arkitekturer. Skrivekonkurrence er blevet betydeligt forbedret. Det er bedst egnet til apps med høje læse/skrive-forhold og krav om global distribution. Til skriveintensive transaktionelle workloads er Neon eller PlanetScale bedre fits.

Hvad skete der med PlanetScales gratisplan?

PlanetScale fjernede sin Hobby (gratis) plan i april 2024. Nye Hobby-databaser blev blokeret 6. marts 2024, og alle eksisterende blev pensioneret 8. april 2024. Det billigste indgangspunkt er nu $5/md. for en Postgres single-node-database. Dette drev mange solo-udviklere til at migrere til Neon eller Turso.

Hvordan påvirker Databricks-opkøbet Neon?

Databricks opkøbte Neon for ~$1 mia. i maj 2025. Siden da har Neon skåret lageromkostningerne med 80%, investeret i AI-agent-workflows og opnået enterprise-kredibilitet. Priserne er blevet billigere, ikke dyrere. Opkøbet signalerer langsigtet stabilitet; Databricks er profitabelt og forpligtet til Neon som dets Postgres-lag.

Understøtter Turso stadig scale-to-zero?

Turso udfasede scale-to-zero for nye brugere i begyndelsen af 2025. Eksisterende brugere på legacy-planer beholder det, men nye tilmeldinger får always-on-instanser. Dette eliminerer cold starts, men fjerner fordelen ved "betal intet, når inaktiv". Edge-replikater blev også indstillet for nye brugere som en del af platformkonsolideringen.

Hvilken serverless database er billigst til et sideprojekt?

Neon og Turso tilbyder begge gratisplaner, der håndterer de fleste sideprojekter. Neon giver dig 0,5 GB lagring og 100 compute-timer. Turso giver dig 5 GB lagring og 500 mio. rækkelæsninger. PlanetScale har ingen gratisplan; minimum er $5/md. Til et typisk sideprojekt med let trafik er enhver af gratisplanerne mere end nok.

Endelig dom

For de fleste udviklere i 2026 er Neon den bedste serverless database at starte med. Den giver dig det fulde Postgres-økosystem, en gratisplan, der faktisk fungerer til rigtige projekter, øjeblikkelig grening til CI/CD og prissætning, der skalerer med forbrug. Databricks-backingen tilføjer enterprise-stabilitet uden enterprise-låsning.

PlanetScale fortjener sin plads, når du har brug for horisontal MySQL-sharding, eller dit team allerede er investeret i MySQL-økosystemet. Turso er det rigtige valg, når edge-latenstid er et målebart krav, ikke bare et nice-to-have.

Vurdér din datamodel, din skaleringsbane og hvor dine brugere er. Vælg derefter én og begynd at bygge; alle tre er produktionsklare, og Postgres/MySQL/SQLite-økosystemerne betyder, at du aldrig er virkelig låst fast.

Kilder

• Neon Architecture Overview
• Neon Pricing
• PlanetScale Pricing
• PlanetScale for Postgres Is Now GA
• Turso Pricing
• Turso libSQL Documentation
• Databricks Agrees to Acquire Neon
• Upcoming Changes to the Turso Platform
• PlanetScale Deprecating the Hobby Plan
• Serverless Database Latency Benchmarks, Pilcrow (2023)
• Drizzle ORM, Connect Turso