Neon vs PlanetScale vs Turso: Postgres, MySQL tai SQLite reunoilla?

Päätös Neon vs PlanetScale vs Turso tiivistyy kolmeen perustavanlaatuiseen valintaan: Postgres, MySQL/Vitess ja SQLite reunoilla (edge). Maisema muuttui dramaattisesti viimeisen vuoden aikana: Databricks osti Neonin noin miljardilla dollarilla, PlanetScale lanseerasi Postgres-tuen ja Turso poisti scale-to-zero -toiminnon käytöstä. Jos valitset serveritonta tietokantaa vuonna 2026, kaikki lukemasi vertailut ovat todennäköisesti vanhentuneita.

Neon vs PlanetScale vs Turso pähkinänkuoressa

Valitse Neon, jos haluat täyden Postgres-yhteensopivuuden, anteliaan ilmaistason ja parhaan Vercel-integraation. Valitse PlanetScale, jos tarvitset MySQL:n yritystason skaalautuvuudella ja horisontaalisella shardauksella. Valitse Turso, jos reunaviive (edge latency) ja monivuokraajaiset database-per-user -arkkitehtuurit ovat tärkeimpiä.

Tässä oli nopea versio. Artikkelin loppuosassa pureudutaan tarkasti siihen, miksi kukin solu näyttää siltä kuin näyttää.

Miten kukin tietokanta toimii kulissien takana?

Jokaisen alustan alla oleva moottori muokkaa kaikkea kyselysyntaksista skaalautumisrajoituksiin. Arkkitehtuurin ymmärtäminen auttaa ennustamaan, miten kukin niistä käyttäytyy sovelluksesi kasvaessa.

Neon: Serveriton Postgres haarautumisella

Neon erottaa laskennan ja tallennuksen toisistaan täysin. Postgres-laskentasolmut ovat efemeerejä: ne käynnistyvät kyselyn saapuessa ja skaalautuvat alas (tai nollaan) ollessaan joutilaina. Tallennus sijaitsee erillisellä pageserver-kerroksella, joka huolehtii kestävyydestä ja palauttamisesta tiettyyn ajankohtaan.

Tämä arkkitehtuuri mahdollistaa Neonin tappava ominaisuus: copy-on-write-haarautumisen. Tietokantahaaran luominen on lähes välitöntä koosta riippumatta, koska se ei kopioi dataa, vaan jakaa tallennussivut emohaaran kanssa ja kirjoittaa uusia sivuja vain datan muuttuessa. Ajattele tätä git branch -komentona tietokannallesi.

• Täysi PostgreSQL-wire-protokolla (pg_dump, psql, kaikki toimii)
• Laskennan automaattinen skaalautuminen 0,25–56 CU:n välillä
• Sisäänrakennettu yhteyksien poolaus PgBouncerin kautta
• Neonin arkkitehtuuri käyttää safekeepereitä write-ahead-log -kestävyyteen

PlanetScale: Vitess-pohjainen MySQL (ja nyt myös Postgres)

PlanetScale pyörii Vitessin päällä, joka on MySQL-klusterointimoottori, alun perin YouTubessa rakennettu heidän tietokantansa shardoimiseksi kymmenientuhansien solmujen yli. Jos tarvitset horisontaalista skaalautuvuutta MySQL:lle, Vitess on olemassa olevista ratkaisuista taistelutestatuin.

PlanetScalen tunnusomainen DX-ominaisuus on deploy-pyynnöt, jotka ovat pohjimmiltaan pull requesteja skeeman muutoksille. Ehdotat migraatiota, tarkistat diffin ja otat sen käyttöön ilman katkoja. Ei lukituksia, ei huoltoikkunoita.

Syyskuusta 2025 lähtien PlanetScale on tarjonnut myös hallinnoidun Postgresin. Se on eri tuote kuin heidän Vitess-tarjontansa: single-node Postgres -tietokannat alkavat hintatasosta 5 $/kk. Horisontaalinen shardaus Postgresille (nimeltään "Neki") on edelleen kehitteillä.

Jos haluat syvempää tietoa siitä, milloin Postgres on järkevämpi valinta kuin MySQL (ja päinvastoin), tutustu PostgreSQL vs MySQL -vertailuumme.

• Vitess: horisontaalinen shardaus, nollakatkoiset skeeman migraatiot
• Postgres: single-node, tuotantovalmis, mutta ilman shardausta vielä
• Deploy-pyynnöt turvallisiin, tarkistettaviin skeaman muutoksiin
• Ei scale-to-zeroa, tietokannat ovat aina käynnissä

Turso: SQLite reunoilla libSQL:n avulla

Turso ottaa täysin erilaisen lähestymistavan. Sen sijaan, että se ajaisi palvelinpohjaista tietokantaa, se käyttää libSQL:ää, joka on avoimen lähdekoodin forkki SQLitesta palvelintilatiloilla. Datasi voi sijaita reunoilla, kirjaimellisesti upotettuna sovelluksesi ajoaikaympäristöön.

Ydinajatus on upotetut replikat: lukureplikat, jotka ajetaan sovellusprosessin sisällä (tai edge-sijainneissa) nollaverkkoviiveellä. Kirjoitukset menevät pääinstanssiin ja levitetään replikoihin asynkronisesti.

• libSQL laajentaa SQLitea HTTP-käytöllä, replikoinnilla ja monivuokraajuudella
• Database-per-user-malli tukee tuhansia eristettyjä tietokantoja
• Kirjoitukset leviävät pääinstanssista replikoihin millisekunneissa
• Ihanteellinen lukuintensiivisille, globaalisti hajautetuille sovelluksille

Tuomio: Neon voittaa arkkitehtuurin laajuudessa. Täysi Postgres välittömällä haarautumisella kattaa laajimman kirjon käyttötapauksia. PlanetScale voittaa, jos tarvitset nimenomaan Vitess-tasoista horisontaalista shardausta. Turso voittaa, jos tarvitset dataa reunoilla.

Miten ne vertautuvat suorituskyvyssä ja viiveessä?

Suorituskyky on kysymys, jonka kehittäjät esittävät ensimmäisenä, ja vastaus riippuu täysin siitä, onko tietokanta "lämmin" vai "kylmä".

Cold start -todellisuuden tarkistus

Neon on ainoa kolmesta, joka yhä tekee scale-to-zeroa oletusarvoisesti. Kun laskentasolmu herää joutilaasta tilasta, odota 400–750 ms viivettä ensimmäisessä kyselyssä. Myöhemmät kyselyt ovat nopeita. Voit eliminoida cold startit asettamalla minimilaskentakoon (0,25 CU maksaa noin 7 $/kk).

PlanetScale on aina ollut aina-päällä-tilassa, ei cold starteja, piste. Tietokantasi on käynnissä riippumatta siitä, kuka sitä kysyy.

Turso poisti scale-to-zero:n käytöstä uusilta käyttäjiltä tammikuussa 2025. Uudet rekisteröitymiset saavat always-on-instansseja, mikä tarkoittaa, ettei cold starteja ole, mutta myöskään ei "maksa nothing kun joutilas" -säästöjä.

Edge-viive: Missä Turso loistaa

Kuumissa kyselyissä kaikki kolme ovat nopeita. Mutta Turson upotetut replikat tarjoavat jotain, mitä kaksi muuta eivät voi: yksinumeroiset millisekuntien lukemisajat reunoilla. Kun SQLite-replikasi elää samassa Cloudflare Workerissa tai Vercel Edge Functionissa kuin koodisi, lukemisissa ei ole lainkaan verkkohyppyä.

Pilcrow'n benchmark-tiedot (heinäkuu 2023 – käsittele suuntaa antavana, ei ajantasaisena) osoittivat PlanetScale HTTP:n olevan ~8 ms, Neon HTTP ~5 ms ja Turso HTTP ~27 ms keskitetyissä kyselyissä. Itsenäiset benchmarkit Cloudflare Workersissa vahvistivat samanlaisia malleja. Nämä luvut ovat PlanetScalen Postgres-julkaisua ja Turson infrastruktuurimuutoksia vanhempia, joten pidä niitä viitekohtina, ei evankeliumina.

Tuomio: Turso voittaa edge-viiveessä. Upotetut replikat nollaverkkohyppyisillä luennolla ovat lyömättömiä. Keskitetyissä työkuormissa, joissa cold startit eivät huoleta, PlanetScalen always-on-johdonmukaisuutta on vaikea voittaa. Neonin cold startit ovat trade-off scale-to-zero -säästöjen vuoksi.

Mitä kukin tietokanta todella maksaa?

Tässä useimmat vertailut epäonnistuvat: ne listaavat suunnitelmien hinnat laskematta, mitä todellinen sovellus maksaisi. Korjataan se.

Ilmaistason erittely

PlanetScale poisti ilmaisen Hobby-tasonsa huhtikuussa 2024. Halvin sisäänkäyntipiste on nyt 5 $/kk single-node Postgres -tietokannasta. Vitess/MySQL-tietokannoille hinnoittelu on klusteripohjaista ja huomattavasti korkeampaa.

Todelliset kuukausikustannukset neljällä skaalatasolla

Nämä arviot perustuvat kunkin alustan virallisiin hinnoittelusivuihin vuoden 2026 hintoihin. Todelliset kustannukset vaihtelevat käyttömallien mukaan.

Muutama asia pistää silmään. Turso on huomattavan halpa ala- ja keskitasoilla, koska sen rivinlukuhinnoittelu suosii lukuintensiivisiä sovelluksia. Neonin käyttöperusteinen hinnoittelu tarkoittaa, että maksat vain siitä, mitä kulutat; joutilas tietokanta ei maksa mitään ilmaistasolla. PlanetScalen hinnoittelu on kilpailukykyistä Postgres single-nodeille, mutta kallistuu Vitess-klustereiden myötä.

PlanetScalen hintakuilu

PlanetScalen suurin heikkous yksinäisille kehittäjille: ilmaistasoa ei ole. Siirryt 0 dollarista (kilpailijan käyttö) vähintään 5 $/kk:hun. Rahoitetuille startup-yrityksille tämä on merkityksetöntä, mutta sivuprojekteille ja prototypoinnille Neonin ja Turson ilmaistasot ovat huomattavasti parempia.

Toisaalta PlanetScalen Vitess-tarjonta tarjoaa horisontaalista shardausta, jota neither Neon nor Turso can match. Jos kirjoitusläpäisykykysi vaatii shardausta, lisähinta on perusteltu.

Tuomio: Neon voittaa useimmille budjeteille. Ilmaistaso plus käyttöperusteinen hinnoittelu on joustavin malli. Turson rivinlukuhinnoittelu on erinomainen lukuintensiivisille sovelluksille. PlanetScale maksaa enemmän alhaalla, mutta tarjoaa yritystason skaalautuvuuden.

Miltä kehittäjäkokemus (DX) näyttää?

Päivittäinen DX on tärkeämpää kuin benchmark-luvut. Tässä vertailu kolmen välillä ominaisuuksista, joita todella käytät.

Tietokannan haarautuminen ja CI/CD

Neonin copy-on-write-haarautuminen on kultastandardi. Luo haara jokaiselle PR:lle, aja migraatiot sitä vastaan, testaa tuotannonkaltaisella datalla ja mergeä. Vercel-integraatio luo haaran automaattisesti jokaiselle preview-deployaukselle.

PlanetScalen deploy-pyynnöt ovat eri versio samasta ideasta. Sen sijaan, että haaroitettaisiin koko tietokanta, haaroitetaan skeema. Ehdota migraatiota, tarkista diff ja ota se käyttöön ilman katkoja. Se on mielipiteellisempi, mutta arguably turvallisempi skeeman muutoksille skaalassa.

Tursolla ei ole haarautumista. Hallitset migraatiot standardilla SQLite-työkalustolla.

ORM-yhteensopivuusmatriisi

Neon ja PlanetScalen Postgres-tarjonta toimivat koko Postgres-ORM-ekosysteemin kanssa out-of-the-box. Turso vaatii libSQL-spesifisiä sovittimia, jotka ovat hyvin ylläpidettyjä, mutta kapeampia.

CLI ja paikallinen kehitys

Kaikilla kolmella on vankat CLI-työkalut: neonctl Neonille, pscale PlanetScalelle ja turso Tursolle. Kukin tukee tietokantojen luomista, haarojen hallintaa (missä sovellettavissa) ja yhdistämistä terminaalista.

Paikallisessa kehityksessä Neonin haarat loistavat: voit kehittää haaraa vastaan, joka peilaa tuotantodataa koskettamatta tuotantoa. PlanetScalen kehityshaarat palvelevat samanlaista tarkoitusta. Turso ajaa SQLitea paikallisesti, joten paikallinen kehitys on äärimmäisen yksinkertaista: osoita vain paikalliseen .db-tiedostoon.

Tuomio: Neon voittaa kehittäjäkokemuksessa. Copy-on-write-haarautuminen Vercel-integraatiolla on paras CI/CD-tarina. PlanetScalen deploy-pyynnöt ovat erinomaisia tiimeille, jotka haluavat skeematason tarkistuksen. Turson yksinkertaisuus on aliarvostettua, mutta siitä puuttuu haarautuminen.

Yhdistäminen Next.js:stä, rinnakkaiset koodiesimerkit

Tässä näkyy, miltä kunkin tietokannan yhdistäminen näyttää Next.js API routesta tai Server Componentista. Nämä ovat copy-paste-valmiita.

Raaka ajuriyhteys (Kaikki kolme)

Neon käyttäen @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 käyttäen @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 käyttäen @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;
}

Huomaa, että Turso käyttää = 1 instead of = true, sillä SQLite:ssä ei ole natiivia boolean-tyyppiä. Pieni ero, mutta se yllättää monet.

Drizzle ORM -asetus (Kaikki kolme)

Jos käytät Drizzlea (ja sinun pitäisi tyypitettyjen kyselyjen vuoksi), tässä konfiguraatio kullekin:

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

Kaikki kolme ajuria toimivat Vercel Edge Functionsissa ja Cloudflare Workersissa. API-pinta on niin samanlainen, että vaihtaminen niiden välillä on lähinnä ajurin vaihtoa; Drizzle-skeemasi ja kyselysi pysyvät samoina (miinus SQL-dialektierot).

Voiko useampaa serveritonta tietokantaa käyttää yhdessä?

Tässä on malli, joka saa jalansijaa yhteisössä, mutta josta mikään vertailuartikkeli ei puhu: Turson käyttö edge-lukemisiin ja Neonin käyttö kirjoituksiin.

Ajatus on suoraviivainen. Ensisijainen datasi elää Neonissa (täysi Postgres, vahva johdonmukaisuus, rikas kyselytuki). Replikoit lukuintensiivisen datan Turson edge-replikoihin, jotka sijaitsevat lähellä käyttäjiäsi globaalisti. Lukemiset osuvat Tursoon alle millisekunnin viiveellä; kirjoitukset menevät Neoniin kestävyyden ja johdonmukaisuuden vuoksi.

Milloin tämä on järkevää:

• Globaalisti hajautetut sovellukset, joissa lukemisviiveellä on väliä (dashboardit, sisältöalustat)
• Monivuokraaja-SaaS, jossa jokaisen vuokraajan lukuintensiivinen data hyötyy edge-välimuistista
• Sovellukset, joissa luku/kirjoitus-suhde on 90/10 ja voit sietää hieman vanhentuneita lukemia

Milloin ohittaa:

• Useimmat sovellukset eivät tarvitse alle 10 ms globaaleja lukemia, yksialueinen Neon-instanssi riittää
• Kahden tietokannan ylläpidon, datan synkronoinnin ja vikojen käsittelyn monimutkaisuus on todellinen
• Jos sovelluksesi on kirjoitusintensiivinen, edge-lukemiset eivät auta paljon

Ole rehellinen itsellesi: jos et operoi globaalissa skaalassa tiukkojen viivevaatimusten kanssa, tämä lisää monimutkaisuutta ilman merkittävää hyötyä. Mutta sovelluksille, jotka sitä tarvitsevat, se on aidosti elegantti malli.

Mitä muuttui vuosina 2025–2026? (Kolme suurta mullistusta)

Jokainen kilpailijavertailu on kirjoitettu ennen näitä tapahtumia. Tässä mitä muuttui ja mitä se tarkoittaa päätöksellesi tänään.

Neon + Databricks: Mitä 1 miljardin dollarin hankinta tarkoittaa

Toukokuussa 2025 Databricks osti Neonin noin miljardilla dollarilla. Tämä ei ollut vain taloudellinen tapahtuma, se muutti Neonin uraa.

Välitön vaikutus: Neon leikkasi tallennuskustannuksia 80 % (1,75 $:sta 0,35 $:aan per Gt-kuukausi). Vantage-analyysi viittaa siihen, että tämä johtui osittain Databricksin AWS-volume-alennuksista, jotka virtasivat Neonin asiakkaille.

Strateginen signaali: Databricks mainitsi, että 80 % Neonin tietokannoista luodaan nyt AI-agenttien toimesta, nousu 30 %:sta GA-vaiheessa. Neon asemoi itsensä oletustietokannaksi AI-vetoiselle kehitykselle, automatisoidulle skeeman luomiselle, agenttihallinnoidulle datalle ja ohjelmalliselle tietokannan provisiointiin.

Sinulle kehittäjänä hankinta tarkoittaa: halvempaa hinnoittelua, yritystason taustatukea (Databricks on kannattava) ja roadmapia, joka on yhä enemmän optimoitu ohjelmallisia/AI-työnkulkuja varten.

PlanetScale Postgres: MySQL ei ole enää ainoa vaihtoehto

Syyskuussa 2025 PlanetScale lanseerasi Postgres-tuen GA:na. Tämä muuttaa täysin vanhan "Neon = Postgres, PlanetScale = MySQL" -kehyksen.

PlanetScale Postgres alkaa hinnasta 5 $/kk single-node-tietokannoille, joissa on ominaisuuksia kuten Query Insights, skeemasuositukset ja haarautuminen. Se on tuotantovalmis ja jo satojen yritysten käytössä. Horisontaalinen shardaus Postgresille (heidän "Neki"-projektinsa) on kuitenkin edelleen kehitteillä.

Mitä tämä tarkoittaa: jos valitset Neon vs PlanetScale pelkästään moottorimieltymysten perusteella, PlanetScale kattaa nyt molemmat. Mutta Neonin Postgres on kypsämpi (se on ollut Postgres-natiivi alusta alkaen), sillä on ilmaistaso ja se tarjoaa syvempää haarautumista copy-on-write-semantiikalla. PlanetScale Postgres on seurannan arvoinen, mutta Neon johtaa edelleen Postgres-puolella.

Turso pudottaa Scale-to-Zeron: Always-on oletusarvoisesti

Tammikuussa 2025 Turso ilmoitti merkittävistä alustamuutoksista: scale-to-zero poistettiin käytöstä uusilta käyttäjiltä, infrastruktuuri konsolidoitiin AWS:ään ja edge-replikat lopetettiin uusilta rekisteröitymisiltä.

Trade-off on selkeä: ei enää cold starteja (hyvä), mutta ei enää "free when idle" -säästöjä (vähemmän hyvä). Legacy-suunnitelmien olemassa olevat käyttäjät säilyttävät scale-to-zero:n, mutta kaikki muut saavat always-on-instansseja.

Tämä tekee Tursosta ennustettavamman: et ylläty cold start -viiveestä, mutta se kaventaa myös kuilua Turson ja PlanetScalen välillä "serverittomuuden" ulottuvuudella. Molemmat ovat nyt always-on hallittuja tietokantoja; Turson edge-tarina on se, mikä erottaa sen.

Neon vs PlanetScale vs Turso: Kumpi kannattaa valita?

Tarpeeksi analyysiä. Tässä on päätöskehys.

Useimmille kehittäjille, jotka aloittavat uuden projektin vuonna 2026, Neon on oletusvalinta. Ilmaistaso, täysi Postgres, välitön haarautuminen ja Vercel-integraatio kattavat 80 % käyttötapauksista. Voit aina skaalata maksullisiin suunnitelmiin tai vaihtaa myöhemmin; Postgres-ekosysteemi tarkoittaa, ettet ole koskaan lukittu sisään.

PlanetScale ansaitsee paikkansa, kun tarvitset MySQL:n yritystason skaalassa tai haluat deploy-pyyntötyönkulun nollakatkoisiin skeaman muutoksiin suurissa tiimeissä.

Turso on oikea valinta, kun arkkitehtuurisi vaatii edge-first-data-accessia tai monivuokraajatietokantojen eristystä skaalassa. Se on erikoistunut työkalu, ja se on erinomainen siinä, mihin se on erikoistunut.

Miten Techsy lähestyy serverittoman tietokannan valintaa

Arvioimme serverittomia tietokantoja neljän ulottuvuuden kautta jokaisessa asiakasprojektissa: datamallin monimutkaisuus, tiimin koko ja SQL-dialektimieltymys, skaalautumisura seuraavien 12–18 kuukauden aikana ja deployment-alusta (Vercel, Cloudflare, AWS jne.).

Oletusstackimme useimmille projekteille on Neon + Drizzle + Next.js. Tässä miksi:

1. Postgres antaa meille rikkaimman ekosysteemin: JSON-sarakkeet, full-text search, PostGIS, laajennukset
2. Neonin haarautuminen mapautuu täydellisesti preview-deployauksiin ja CI-putkiin
3. Ilmaistaso antaa meille mahdollisuuden prototypoida ilman laskutusoverheadia varhaisen vaiheen asiakkaille
4. Drizzlen tyypitettyys havaitsee skeeman driftin ennen kuin se osuu tuotantoon

Kun suosittelemme vaihtoehtoja:

• PlanetScale tiimeille, jotka migroivat olemassa olevasta MySQL-infrasta, jossa kyselyjen uudelleenkirjoittaminen ei ole käytännöllistä
• Turso asiakkaille, jotka rakentavat globaalisti hajautettuja, lukuintensiivisiä tuotteita, joissa edge-viive on mitattava liiketoimintametriikka
• Joskus rehellinen vastaus on "käytä vain Supabasea", kun tarvitset auth + database + storage yhdistettynä yhteen hallittuun pakettiin

Tarvitsetko apua oikean tietokannan valinnassa seuraavaan projektiisi? Hanki ilmainen backend-konsultointi.

FAQ

Onko Neon parempi kuin PlanetScale?

Riippuu tarpeistasi. Neon on parempi Postgres-natiiveille tiimeille, tarjoaa ilmaistason ja syvemmän tietokannan haarautumisen copy-on-write-semantiikalla. PlanetScale on parempi MySQL-työkuormille yritysskaalassa Vitess-shardauksella ja nollakatkoisilla deploy-pyynnöillä. Koska PlanetScale tarjoaa nyt myös Postgresia, kuilu kapenee, mutta Neonin Postgres on kypsämpi.

Mikä on ero Neonin ja Turson välillä?

Neon on serveriton PostgreSQL, jossa laskenta ja tallennus on erotettu ja haarautuminen on välitöntä. Turso on SQLite-pohjainen (libSQL) upotetuilla replikoilla edge-lukemisia varten. Valitse Neon täyden Postgres-ekosysteemin ja haarautumistyönkulujen vuoksi. Valitse Turso globaalien alhaisen viiveen lukemisten ja monivuokraaja-database-per-user-arkkitehtuurien vuoksi.

Onko PlanetScale edelleen sen arvoinen ilman ilmaistasoa?

Hobiprojekteille, todennäköisesti ei; sekä Neon että Turso tarjoavat anteliaat ilmaistasot. Rahoitetuille startup-yrityksille ja yrityksille, jotka tarvitsevat Vitess-pohjaista horisontaalista shardausta tai nollakatkoisia deploy-pyyntöjä, PlanetScalen hinnoittelu on perusteltua. 5 $/kk Postgres-sisäänkäyntipiste on kilpailukykyinen, vaikka ei olekaan ilmainen.

Mikä on paras serveriton tietokanta Next.js:lle?

Neon, useimmille kehittäjille. Sillä on syvin Vercel-integraatio (haara per preview-deployaus), se toimii kaikkien Postgres-ORM:ien kanssa ja alkaa ilmaiseksi. Turso on valinta, jos tarvitset nimenomaan globaaleja edge-lukemisia. Kaikilla kolmella on ajurit, jotka toimivat Vercel Edge Functionsissa.

Kuinka huonoja Neonin cold startit ovat tuotannossa?

Odota 400–750 ms viivettä ensimmäisessä kyselyssä, kun laskenta herää nollasta. Myöhemmät kyselyt ovat nopeita (yksinumeroiset ms). Aina reagoiville sovelluksille aseta minimilaskenta 0,25 CU:hun (noin 7 $/kk Launch-suunnitelmassa) pitääksesi instanssin lämpimänä ja eliminoidaksesi cold startit kokonaan.

Voiko PlanetScale käyttää PostgreSQL:ää nyt?

Kyllä, syyskuusta 2025 lähtien. PlanetScale lanseerasi PostgreSQL-tuen GA:na, single-node-tietokannat alkaen hinnasta 5 $/kk. Se on tuotantovalmis, ja sadat yritykset käyttävät sitä. Horisontaalinen shardaus Postgresille on kuitenkin edelleen kehitteillä; sitä varten tarvitset heidän Vitess/MySQL-tarjontansa.

Onko Turso hyvä tuotantosovelluksille?

Kyllä, varauksin. Turso loistaa lukuintensiivisissä työkuormissa ja monivuokraaja-arkkitehtuureissa. Kirjoitusten samanaikaisuus on parantunut merkittävästi. Se sopii parhaiten sovelluksille, joissa on korkea luku/kirjoitus-suhde ja globaalit jakeluvaatimukset. Kirjoitusintensiivisiin transaktionaalisiin työkuormiin Neon tai PlanetScale ovat parempia valintoja.

Mitä tapahtui PlanetScalen ilmaistasolle?

PlanetScale poisti Hobby (ilmaisen) tasonsa huhtikuussa 2024. Uudet Hobby-tietokannat estettiin 6. maaliskuuta 2024, ja kaikki olemassa olevat poistettiin käytöstä 8. huhtikuuta 2024. Halvin sisäänkäyntipiste on nyt 5 $/kk Postgres single-node -tietokannasta. Tämä ajoi monet yksinäiset kehittäjät migratoimaan Neoniin tai Tursoon.

Miten Databricks-hankinta vaikuttaa Neoniin?

Databricks osti Neonin ~1 Mrd $:lla toukokuussa 2025. Sen jälkeen Neon on leikannut tallennuskustannuksia 80 %, investoinut AI-agenttityönkulkuihin ja saanut yritystason uskottavuutta. Hinnoittelu on halventunut, ei kallistunut. Hankinta signaloi pitkän aikavälin vakautta; Databricks on kannattava ja sitoutunut Neoniin Postgres-kerroksenaan.

Tukeeko Turso edelleen scale-to-zeroa?

Turso poisti scale-to-zero:n käytöstä uusilta käyttäjiltä vuoden 2025 alussa. Olemassa olevat käyttäjät legacy-suunnitelmissa säilyttävät sen, mutta uudet rekisteröitymiset saavat always-on-instansseja. Tämä eliminoi cold startit, mutta poistaa "maksa nothing kun joutilas" -edun. Edge-replikat lopetettiin myös uusilta käyttäjiltä osana alustan konsolidointia.

Mikä serveriton tietokanta on halvin sivuprojektille?

Neon ja Turso tarjoavat molemmat ilmaistasoja, jotka hoitavat useimmat sivuprojektit. Neon antaa 0,5 Gt tallennustilaa ja 100 laskentatuntia. Turso antaa 5 Gt tallennustilaa ja 500M rivinlukua. PlanetScalella ei ole ilmaistasoa, minimi on 5 $/kk. Tyypilliselle sivuprojektille, jossa on kevyt liikenne, kumpikin ilmaistaso on enemmän kuin tarpeeksi.

Lopullinen tuomio

Useimmille kehittäjille vuonna 2026 Neon on paras serveriton tietokanta, jolla aloittaa. Se antaa sinulle täyden Postgres-ekosysteemin, ilmaistason, joka todella toimii oikeissa projekteissa, välittömän haarautumisen CI/CD:tä varten ja hinnoittelun, joka skaalautuu käytön mukaan. Databricks-tausta lisää yritystason vakautta ilman yrityslukitusta.

PlanetScale ansaitsee paikkansa, kun tarvitset horisontaalista MySQL-shardausta tai tiimisi on jo investoinut MySQL-ekosysteemiin. Turso on oikea valinta, kun edge-viive on mitattava vaatimus, ei vain mukava lisäominaisuus.

Arvioi datamallisi, skaalautumisurasi ja missä käyttäjäsi ovat. Valitse sitten yksi ja aloita rakentaminen; kaikki kolme ovat tuotantovalmiita, ja Postgres/MySQL/SQLite-ekosysteemit tarkoittavat, ettet ole koskaan todella lukittu sisään.

Lähteet

• 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