Neon vs PlanetScale vs Turso: Postgres, MySQL eller SQLite i Edge?

Valet mellan Neon, PlanetScale och Turso handlar om tre fundamentalt olika satsningar: Postgres, MySQL/Vitess och SQLite i edge. Landskapet förändrades dramatiskt under det senaste året -- Databricks förvärvade Neon för ungefär 1 miljard dollar, PlanetScale lanserade Postgres-stöd och Turso fasade ut scale-to-zero. Om du väljer en serverlös databas 2026 är förmodligen varje jämförelse du har läst föråldrad.

Neon vs PlanetScale vs Turso i Korthet

Välj Neon om du vill ha fullständig Postgres-kompatibilitet, en generös gratisplan och den bästa Vercel-integrationen. Välj PlanetScale om du behöver MySQL i enterprise-skala med horisontell sharding. Välj Turso om edge-latens och multi-tenant en-databas-per-användare-arkitekturer är viktigast.

Det var den korta versionen. Resten av den här artikeln förklarar exakt varför varje cell ser ut som den gör.

Hur Fungerar Varje Databas Under Huven?

Motorn under varje plattform påverkar allt från frågesyntax till skalningsgränser. Att förstå arkitekturen hjälper dig förutsäga hur varje databas beter sig när din app växer.

Neon: Serverlöst Postgres med Branching

Neon separerar compute helt från lagring. Dina Postgres compute-noder är efemära -- de startar när en fråga anländer och skalar ned (eller till noll) när de är inaktiva. Lagringen finns på ett separat pageserver-lager som hanterar hållbarhet och point-in-time-återställning.

Den här arkitekturen möjliggör Neons nyckelfeatur: copy-on-write-branching. Att skapa en databasgren är nästan omedelbart oavsett storlek eftersom inga data kopieras -- lagringssidor delas med föräldern och bara nya sidor skrivs när data ändras. Tänk git branch för din databas.

• Fullständigt PostgreSQL-trådprotokoll (pg_dump, psql, allt fungerar)
• Autoskalning compute från 0,25 till 56 CU
• Inbyggd anslutningspoolning via PgBouncer
• Neons arkitektur använder safekeepers för write-ahead-log-hållbarhet

PlanetScale: Vitess-Driven MySQL (och Nu Postgres)

PlanetScale körs på Vitess, MySQL-klustermotorn som ursprungligen byggdes på YouTube för att sharda deras databas över tiotusentals noder. Om du behöver horisontell skalning för MySQL är Vitess den mest stridstestade lösningen som finns.

PlanetScales signaturs-DX-funktion är deploy requests -- i princip pull requests för schemaändringar. Du föreslår en migration, granskar diff:en och tillämpar den utan driftstopp. Ingen låsning, inga underhållsfönster.

Sedan september 2025 erbjuder PlanetScale också hanterat Postgres. Det är en annan produkt än deras Vitess-erbjudande -- Postgres-databaser med en nod från 500 kr/mån. Horisontell sharding för Postgres (kallad "Neki") är fortfarande under utveckling.

För en djupare dykning om när Postgres ger mer mening än MySQL (och vice versa), kolla in vår PostgreSQL vs MySQL-jämförelse.

• Vitess: horisontell sharding, schemamigreringar utan driftstopp
• Postgres: enkelnod, produktionsklar, men utan sharding ännu
• Deploy requests för säkra, granskningsbara schemaändringar
• Ingen scale-to-zero -- databaser körs alltid

Turso: SQLite i Edge med libSQL

Turso tar ett helt annorlunda tillvägagångssätt. Istället för att köra en serverbaserad databas använder det libSQL -- en öppen källkodsgaffel av SQLite med serverlägeskapaciteter. Dina data kan leva i edge, bokstavligen inbäddade i din applikations körtid.

Kärnkonceptet är inbäddade repliker: läsrepliker som körs inuti din applikationsprocess (eller på edge-platser) med nollnätverkslatensläsningar. Skrivningar går till en primär instans och sprids till repliker asynkront.

• libSQL utökar SQLite med HTTP-åtkomst, replikering och multi-tenancy
• Databas-per-användare-modellen stöder tusentals isolerade databaser
• Skrivningar sprids från primär till repliker på millisekunder
• Idealisk för läsintensiva, globalt distribuerade appar

Omdöme: Neon vinner i arkitekturbredd. Fullständigt Postgres med omedelbar branching täcker det bredaste utbudet av användningsfall. PlanetScale vinner om du specifikt behöver Vitess-gradens horisontella sharding. Turso vinner om du behöver data i edge.

Hur Jämför De Sig på Prestanda och Latens?

Prestanda är frågan som utvecklare ställer först, och svaret beror helt på om din databas är varm eller kall. Se även vår Supabase vs Firebase-jämförelse.

Kall Start-Verklighetscheck

Neon är den enda av de tre som fortfarande gör scale-to-zero som standard. När din compute-nod vaknar från inaktivitet, förvänta dig 400–750 ms på den första frågan. Efterföljande frågor är snabba. Du kan eliminera kalla starter genom att ange en minsta compute-storlek (0,25 CU kostar ungefär 70 kr/mån).

PlanetScale har alltid varit alltid-på -- inga kalla starter, punkt. Din databas körs oavsett om någon frågar den eller inte.

Turso fasade ut scale-to-zero för nya användare i januari 2025. Nya registreringar får alltid-på-instanser, vilket innebär inga kalla starter men heller inga "betala ingenting när inaktiv"-besparingar.

Edge-Latens: Där Turso Utmärker Sig

För heta frågor är alla tre snabba. Men Tursos inbäddade repliker levererar något som de andra två inte kan: ensiffrigt millisekund-läsningar i edge. När din SQLite-replik lever i samma Cloudflare Worker eller Vercel Edge Function som din kod finns det inget nätverkshopp för läsningar alls.

Benchmarkdata från Pilcrow (juli 2023 -- behandla som riktgivande, inte aktuellt) visade PlanetScale HTTP på ~8 ms, Neon HTTP på ~5 ms och Turso HTTP på ~27 ms för centraliserade frågor. Dessa siffror föregår PlanetScales Postgres-lansering och Tursos infrastrukturförändringar, så ta dem som referenspunkter.

Omdöme: Turso vinner på edge-latens. Inbäddade repliker med nollnätverkshopp-läsningar är oöverträffade. För centraliserade arbetsbelastningar utan cold start-bekymmer är PlanetScales alltid-på-konsistens svår att slå. Neons kalla starter är avvägningen för scale-to-zero-besparingar.

Vad Kostar Varje Databas Egentligen?

Det är här de flesta jämförelser brister -- de listar planpriser utan att räkna ut vad en riktig app skulle betala. Låt oss fixa det.

Gratisplan-Uppdelning

PlanetScale avvecklade sin gratis Hobby-plan i april 2024. Den billigaste ingångspunkten är nu 500 kr/mån för en Postgres-databas med en nod. För Vitess/MySQL-databaser är prissättningen klusterbaserad och betydligt högre.

Verklig Månadskostnad på Fyra Skalningsnivåer

Dessa uppskattningar använder aktuella 2026-priser från varje plattforms officiella prissidor. Faktiska kostnader varierar beroende på användningsmönster.

Några saker sticker ut. Turso är anmärkningsvärt billigt på låg- och mellannivåerna eftersom dess radläsningsprissättningsmodell gynnar läsintensiva appar. Neons användningsbaserade prissättning innebär att du bara betalar för vad du förbrukar -- inaktiva databaser kostar ingenting på gratisplanen. PlanetScales prissättning är konkurrenskraftig för Postgres enkelnoder men eskalerar med Vitess-kluster.

PlanetScales Prisbrant

PlanetScales största svaghet för solo-utvecklare: det finns ingen gratisplan. Du går från 0 kr (med en konkurrent) till minst 500 kr/mån. För finansierade startups är detta irrelevant, men för sidoprojekt och prototypande är Neons och Tursos gratisplaner meningsfullt bättre.

Å andra sidan tillhandahåller PlanetScales Vitess-erbjudande horisontell sharding som varken Neon eller Turso kan matcha. Om ditt skrivgenomflöde kräver sharding är premiet motiverat.

Omdöme: Neon vinner för de flesta budgetar. Gratisplanen plus användningsbaserad prissättning är den mest flexibla modellen. Tursos radläsningsprissättning är utmärkt för läsintensiva appar. PlanetScale kostar mer i det låga änden men levererar skalning i enterprise-klass.

Hur Är Utvecklarupplevelsen?

Daglig DX spelar mer roll än benchmarksiffror. Så här jämför de tre på de funktioner du faktiskt kommer att använda.

Databasbranching och CI/CD

Neons copy-on-write-branching är guldstandarden. Skapa en gren för varje PR, kör migreringar mot den, testa med produktionsliknande data och slå ihop. Vercel-integrationen skapar automatiskt en gren per förhandsgranskningsdriftsättning.

PlanetScales deploy requests är en annan variant av samma idé. Istället för att grena hela databasen grenar du schemat. Föreslå en migrering, granska diff:en och tillämpa den utan driftstopp. Det är mer åsiktsfullt men förmodligen säkrare för schemaändringar i stor skala. Du kan också vara intresserad av bästa AI-stack för SaaS.

Turso har ingen branching. Du hanterar migreringar med standard SQLite-verktyg.

ORM-Kompatibilitetsmatris

Neon och PlanetScales Postgres-erbjudande fungerar med hela Postgres-ORM-ekosystemet direkt. Turso kräver libSQL-specifika adaptrar, som är välunderhållna men smalare.

CLI och Lokal Utveckling

Alla tre har solida CLI:er: neonctl för Neon, pscale för PlanetScale och turso för Turso. Var och en stöder skapande av databaser, hantering av grenar (där tillämpligt) och anslutning från din terminal.

För lokal utveckling lyser Neon-grenar -- du kan utveckla mot en gren som speglar produktionsdata utan att röra produktion. PlanetScales utvecklingsgrenar tjänar ett liknande syfte. Turso kör SQLite lokalt, så lokal utveckling är extremt enkel -- peka bara på en lokal .db-fil.

Omdöme: Neon vinner på utvecklarupplevelse. Copy-on-write-branching med Vercel-integration är den bästa CI/CD-historien. PlanetScales deploy requests är utmärkta för team som vill ha schemarnivågranskning. Tursos enkelhet är underskattad men saknar branching.

Ansluta från Next.js -- Sida-vid-Sida-Kod

Så här ser det ut att ansluta till varje databas från en Next.js API-rutt eller Server Component. Dessa är redo att kopiera och klistra in.

Raw Driver-Anslutning (Alla Tre)

Neon med @neondatabase/serverless:

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

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

// Fungerar i Edge Runtime och 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,
});

// Fungerar i Edge Runtime och 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,
});

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

Notera att Turso använder = 1 istället för = true -- SQLite har ingen inbyggd boolesk typ. Liten skillnad, men den överraskar folk.

Drizzle ORM-Inställning (Alla Tre)

Om du använder Drizzle (och du bör förmodligen det för typsäkra frågor), här är konfigurationen för var och en:

// 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);

Alla tre drivrutiner fungerar i Vercel Edge Functions och Cloudflare Workers. API-ytan är tillräckligt lik för att byta mellan dem i princip är ett drivrutinsbyte -- ditt Drizzle-schema och frågor förblir desamma (minus SQL-dialektskillnader).

Kan Man Använda Flera Serverlösa Databaser Tillsammans?

Här är ett mönster som vinner mark i gemenskapen men ingen jämförelseartiklar pratar om: att använda Turso för edge-läsningar och Neon för skrivningar.

Idén är enkel. Dina primärdata lever i Neon (fullständigt Postgres, stark konsistens, rikt frågstöd). Du replikerar läsintensiva data till Turso edge-repliker som sitter nära dina användare globalt. Läsningar träffar Turso med sub-millisekunds latens; skrivningar går till Neon för hållbarhet och konsistens.

När detta är meningsfullt:

• Globalt distribuerade appar där läslatens spelar roll (instrumentpaneler, innehållsplattformar)
• Multi-tenant SaaS där varje tenants läsintensiva data drar nytta av edge-caching
• Appar med ett 90/10-läs/skriv-förhållande där du kan tolerera något inaktuella läsningar

När du hoppar över det:

• De flesta appar behöver inte sub-10 ms globala läsningar -- en enregions Neon-instans räcker
• Komplexiteten med att underhålla två databaser, synkronisera data och hantera fel är verklig
• Om din app är skrivintensiv hjälper edge-läsningar inte mycket

Var ärlig mot dig själv: om du inte arbetar i global skala med strikta latenskrav lägger detta till komplexitet utan meningsfull nytta. Men för de appar som behöver det är det ett genuint elegant mönster.

Vad Förändrades 2025–2026? (De Tre Stora Omvälvningarna)

Varje konkurrentjämförelse skrevs innan dessa händelser. Här är vad som förändrades och vad det innebär för ditt beslut idag. Läs mer om Prisma vs Drizzle ORM-jämförelse.

Neon + Databricks: Vad 1-Miljard-Dollar-Förvärvet Innebär

I maj 2025 förvärvade Databricks Neon för ungefär 1 miljard dollar. Det var inte bara en finansiell händelse -- det förändrade Neons bana.

Den omedelbara påverkan: Neon sänkte lagringskostnaderna med 80 % (från 1,75 dollar till 0,35 dollar per GB-månad). Vantage-analysen tyder på att detta delvis kom från Databricks AWS-volymrabatter som flödade igenom till Neon-kunder.

Den strategiska signalen: Databricks noterade att 80 % av Neon-databaser nu skapas av AI-agenter, upp från 30 % vid GA. Neon positionerar sig som standarddatabas för AI-driven utveckling -- automatiserad schemauppbyggnad, agentskötade data, programmatisk databasförsörjning.

För dig som utvecklare innebär förvärvet: billigare prissättning, enterprise-backing (Databricks är lönsamt) och en färdplan som allt mer optimeras för programmatiska/AI-arbetsflöden.

PlanetScale Postgres: MySQL är inte Längre det Enda Alternativet

I september 2025 lanserade PlanetScale Postgres-stöd som GA. Det förändrar helt det gamla "Neon = Postgres, PlanetScale = MySQL"-inramningen.

PlanetScale Postgres börjar på 500 kr/mån för enkelnodsdatabaser med funktioner som Query Insights, schemarekommendationer och branching. Det är produktionsklart och körs redan på hundratals företag. Horisontell sharding för Postgres (deras "Neki"-projekt) är dock fortfarande under utveckling.

Vad detta innebär: om du väljer mellan Neon vs PlanetScale rent på motorpreferens täcker PlanetScale nu båda. Men Neons Postgres är mer mogen (det har varit Postgres-nativt från dag ett), har en gratisplan och erbjuder djupare branching med copy-on-write-semantik. PlanetScale Postgres är värt att bevaka men Neon leder fortfarande på Postgres-sidan.

Turso Avvecklar Scale-to-Zero: Alltid-På som Standard

I januari 2025 tillkännagav Turso betydande plattformsförändringar: scale-to-zero avvecklat för nya användare, infrastrukturkonsolidering till AWS och edge-repliker avvecklade för nya registreringar.

Avvägningen är tydlig: inga fler kalla starter (bra), men inga fler "gratis när inaktiv"-besparingar (mindre bra). Befintliga användare på legacy-planer behåller scale-to-zero, men alla andra får alltid-på-instanser.

Det gör Turso mer förutsägbart -- du överraskas inte av cold start-latens -- men det minskar också klyftan mellan Turso och PlanetScale på "serverlösa"-dimensionen. Båda är nu alltid-på hanterade databaser; Tursos edge-berättelse är det som differentierar det.

Neon vs PlanetScale vs Turso: Vilket Ska Du Välja?

Nog med analys. Här är beslutsramverket.

För de flesta utvecklare som startar ett nytt projekt 2026 är Neon standardvalet. Gratisplan, fullständigt Postgres, omedelbar branching och Vercel-integration täcker 80 % av användningsfallen. Du kan alltid skala upp till betalda planer eller byta senare -- Postgres-ekosystemet innebär att du aldrig är inlåst.

PlanetScale förtjänar sin plats när du behöver MySQL i enterprise-skala eller vill ha deploy request-arbetsflödet för schemaändringar utan driftstopp i stora team.

Turso är rätt val när din arkitektur kräver edge-first dataåtkomst eller multi-tenant databasisolering i skala. Det är ett specialiserat verktyg, och det är utmärkt på det det specialiserar sig på.

Hur Techsy Tar Sig An Val av Serverlösa Databaser

Vi utvärderar serverlösa databaser längs fyra dimensioner för varje kundprojekt: datamodellkomplexitet, teamstorlek och SQL-dialektpreferens, skalningsbana de närmaste 12–18 månaderna och driftsättningsplattform (Vercel, Cloudflare, AWS, etc.).

Vår standardstack för de flesta projekt är Neon + Drizzle + Next.js. Här är varför:. Kolla in vår Vercel vs Netlify-jämförelse.

1. Postgres ger oss det rikaste ekosystemet -- JSON-kolumner, fulltextsökning, PostGIS, tillägg
2. Neons branching kartlägger perfekt till förhandsgranskningsdriftsättningar och CI-pipelines
3. Gratisplanen låter oss prototypa utan faktureringsoverhead för tidiga kunder
4. Drizzles typsäkerhet fångar schemadrift innan den når produktion

När vi rekommenderar alternativ:

• PlanetScale för team som migrerar från befintlig MySQL-infrastruktur där omskrivning av frågor inte är praktiskt
• Turso för kunder som bygger globalt distribuerade, läsintensiva produkter där edge-latens är ett mätbart affärsmätetal
• Ibland är det ärliga svaret "använd bara Supabase" när du behöver auth + databas + lagring i ett hanterat paket

Behöver du hjälp med att välja rätt databas för ditt nästa projekt? Få en gratis backend-konsultation.

Vanliga Frågor

Är Neon Bättre än PlanetScale?

Det beror på dina behov. Neon är bättre för Postgres-nativa team, erbjuder en gratisplan och har djupare databasbranching med copy-on-write-semantik. PlanetScale är bättre för MySQL-arbetsbelastningar i enterprise-skala med Vitess-sharding och deploy requests utan driftstopp. Eftersom PlanetScale nu erbjuder Postgres också minskar klyftan -- men Neons Postgres är mer moget.

Vad är Skillnaden Mellan Neon och Turso?

Neon är serverlöst PostgreSQL med compute-lagringsavskiljning och omedelbar branching. Turso är SQLite-baserat (libSQL) med inbäddade repliker för edge-läsningar. Välj Neon för det fullständiga Postgres-ekosystemet och branching-arbetsflöden. Välj Turso för globala låglatens-läsningar och multi-tenant databas-per-användare-arkitekturer.

Är PlanetScale Fortfarande Värt det Utan en Gratisplan?

För hobbyprojekt, förmodligen inte -- Neon och Turso erbjuder båda generösa gratisplaner. För finansierade startups och företag som behöver Vitess-driven horisontell sharding eller deploy requests utan driftstopp är PlanetScales prissättning motiverad. 500-kr/mån Postgres-ingångspunkten är konkurrenskraftig, men inte gratis.

Vilken är den Bästa Serverlösa Databasen för Next.js?

Neon, för de flesta utvecklare. Den har den djupaste Vercel-integrationen (gren per förhandsgranskningsdriftsättning), fungerar med alla Postgres-ORM:ar och börjar gratis. Turso är valet om du specifikt behöver globala edge-läsningar. Alla tre har drivrutiner som fungerar i Vercel Edge Functions.

Hur Dåliga är Neons Cold Starts i Produktion?

Förvänta dig 400–750 ms på den första frågan när compute vaknar från inaktivitet. Efterföljande frågor är snabba (ensiffrigt ms). För alltid-responsiva appar, ange minsta compute till 0,25 CU (ungefär 70 kr/mån på Launch-planen) för att hålla instansen varm och eliminera kalla starter helt.

Kan PlanetScale Använda PostgreSQL Nu?

Ja, sedan september 2025. PlanetScale lanserade PostgreSQL-stöd som GA, med enkelnodsdatabaser från 500 kr/mån. Det är produktionsklart med hundratals företag som kör på det. Horisontell sharding för Postgres är dock fortfarande under utveckling -- för det behöver du deras Vitess/MySQL-erbjudande.

Är Turso Bra för Produktionsappar?

Ja, med förbehåll. Turso utmärker sig i läsintensiva arbetsbelastningar och multi-tenant-arkitekturer. Skrivkoncurrens har förbättrats avsevärt. Det passar bäst för appar med höga läs-/skriv-förhållanden och globala distributionskrav. För skrivintensiva transaktionsarbetsbelastningar är Neon eller PlanetScale bättre val.

Vad Hände med PlanetScales Gratisplan?

PlanetScale tog bort sin Hobby (gratis) plan i april 2024. Nya Hobby-databaser blockerades 6 mars 2024, och alla befintliga avvecklades 8 april 2024. Den billigaste ingångspunkten är nu 500 kr/mån för en Postgres enkelnodsdatabas. Det fick många solo-utvecklare att migrera till Neon eller Turso.

Hur Påverkar Databricks-Förvärvet Neon?

Databricks förvärvade Neon för ~1 miljard dollar i maj 2025. Sedan dess har Neon sänkt lagringskostnaderna med 80 %, investerat i AI-agent-arbetsflöden och vunnit enterprise-trovärdighet. Prissättningen har blivit billigare, inte dyrare. Förvärvet signalerar långsiktig stabilitet -- Databricks är lönsamt och engagerat i Neon som sitt Postgres-lager.

Stöder Turso Fortfarande Scale-to-Zero?

Turso avvecklade scale-to-zero för nya användare i början av 2025. Befintliga användare på legacy-planer behåller det, men nya registreringar får alltid-på-instanser. Det eliminerar kalla starter men tar bort "betala ingenting när inaktiv"-fördelen. Edge-repliker avvecklades också för nya användare som en del av plattformskonsolideringen.

Vilken Serverlös Databas är Billigast för ett Sidoprojekt?

Neon och Turso erbjuder båda gratisplaner som hanterar de flesta sidoprojekt. Neon ger dig 0,5 GB lagring och 100 compute-timmar. Turso ger dig 5 GB lagring och 500 miljoner radläsningar. PlanetScale har ingen gratisplan -- minimum är 500 kr/mån. För ett typiskt sidoprojekt med lätt trafik räcker endera gratisplanen mer än väl.

Slutomdöme

För de flesta utvecklare 2026 är Neon den bästa serverlösa databasen att börja med. Den ger dig det fullständiga Postgres-ekosystemet, en gratisplan som faktiskt fungerar för riktiga projekt, omedelbar branching för CI/CD och prissättning som skalar med användning. Databricks-backingen lägger till enterprise-stabilitet utan enterprise-inlåsning.

PlanetScale förtjänar sin plats när du behöver horisontell MySQL-sharding eller ditt team redan är investerat i MySQL-ekosystemet. Turso är rätt val när edge-latens är ett mätbart krav, inte bara ett bra-att-ha.

Bedöm din datamodell, din skalningsbana och var dina användare finns. Välj sedan en och börja bygga -- alla tre är produktionsklara, och Postgres/MySQL/SQLite-ekosystemen innebär att du aldrig är riktigt inlåst.

Källor

• Neons Arkitekturöversikt
• Neon-prissättning
• PlanetScale-prissättning
• PlanetScale för Postgres är nu GA
• Turso-prissättning
• Turso libSQL-dokumentation
• Databricks Accepterar att Förvärva Neon
• Kommande Förändringar av Turso-Plattformen
• PlanetScale Avvecklar Hobby-Planen
• Serverlösa databas-latens-benchmarks -- Pilcrow (2023)
• Drizzle ORM -- Anslut Turso