Neon эсвэл Supabase: ижил Postgres-ийн clone хийх арга 23 дахин зөржээ

Нэг AWS бүсэд хийсэн 469 сорьцтой хэмжилтэд Neon-ийн унших реплика эхний SQL асуулгад бэлэн болохдоо Supabase-ийнхээс 23 дахин хурдан байв. Энэ нь унших реплика үүсгэх үр дүн; өгөгдлийн branch үүсэх хурд эсвэл бүх төрлийн SQL асуулгын давуу тал гэсэн үг биш. Үйлдвэрлэлийн өгөгдлийн төлөвтэй preview сан байнга хэрэгтэй багт Neon, харин Postgres-тай хамт Auth, Storage, API болон Realtime ашиглах MVP-д Supabase илүү тохирох сонголт.

Production backend-ийн сонголт илүү нөхцөлтэй. Хэрэглэгчийн нэвтрэлт, файл, API-гаа Supabase-ийн багцад төвлөрүүлэх бол түүний сарын суурь үнэ ойлгомжтой; эдгээрийг өөрөөр шийдсэн багт Neon-ийн өгөгдөлтэй branch, унших реплика, хэрэглээгээр тооцох загвар илүү үнэ цэнтэй байж болно. Реплика, branch, сэргээх түүх нь өөр өөр ажил хийдэг учраас тэдгээрийн хурд болон зардлыг тусад нь авч үзэх шаардлагатай.

Хэмжилтийн зөрүү юуг харуулсан бэ

Туршилтад хоёр үйлчилгээг нэг бүсэд байрлуулж, ойролцоох үйлчлүүлэгчээс давтан холбогдсон. Холболт, TLS, баталгаажуулалт болон нэг SQL асуулгыг хамтад нь хэмжихэд ердийн асуулгын медиан хугацаа ойролцоо гарсан. Ийм үр дүнгээр Neon дээр ажиллуулах бүх workload Supabase-ээс хурдан гэж дүгнэх үндэсгүй.

Унших реплика шинээр босгоход архитектурын ялгаа тодорсон: Neon-ийн реплика үндсэн сангийн хадгалалтыг хуваалцдаг бол хэмжилтэд ашигласан Supabase-ийн реплика өгөгдлийн сангийн тусдаа хуулбар үүсгэдэг. Реплика бэлэн болох хугацаа нь уншилтын ачааллыг салгах үед хэрэгтэй үзүүлэлт боловч ажиллаж эхэлсний дараах асуулгын хоцролтыг орлохгүй. Түүнчлэн реплика нь эх сангийн өөрчлөлтийг дагадаг тул өгөгдлийн өмнөх төлөвт буцах нөөц хуулбарын үүрэг гүйцэтгэхгүй.

Шинэ төсөл үүсгээд эхний асуулгад хүрэх, идэвхгүй болсон compute-ийг сэрээх, өгөгдлийн branch нээх зэрэг нь мөн тус тусдаа хэмжүүр юм. Preview орчин бүрт юу шинээр үүсгэхээс шалтгаалан хүлээлтийн хугацаа өөрчлөгдөнө. Иймээс ганц хурдны тоог сарын зардал эсвэл хэрэглэгчид мэдрэгдэх хариу өгөх хугацааны шууд таамаг болгон ашиглах нь төөрөгдүүлнэ.

Preview branch-д ямар өгөгдөл очих вэ

Neon-ийн branch эх салбарын схем болон тухайн мөчийн өгөгдлийн төлөвийг авч, цаашдын өөрчлөлтөө тусад нь хадгалдаг. Энэ нь migration, өгөгдлөөс хамаарах логик эсвэл үйлдвэрлэлийн төлөвтэй ойролцоо нөхцөлийг шалгах preview санд тохирно. Харин бодит хэрэглэгчийн мэдээлэл салбарт орж болох тул түр орчны хандалт, хадгалах хугацаа, цэвэрлэх журмыг production-ийн шаардлагатай уялдуулах хэрэгтэй.

Supabase-ийн dashboard branching зааварт шинэ branch анхдагчаар production өгөгдөл болон Storage-ийн объектгүй, харин схем, тохиргоо, Edge Functions-той эхэлдэг гэж тайлбарласан. Dashboard-аас өгөгдөл хамтатгах сонголт нь PITR нэмэлттэй төсөлд хамаарна. Схем, API, тохиргооны өөрчлөлт шалгахад өгөгдөлгүй орчин хангалттай байж болох ч үйлдвэрлэлийн бичлэгүүд шаардлагатай бол энэ нөхцөл сонголтод шууд нөлөөлнө.

Хоёр үйлчилгээний branch-ийг ижил «clone» гэж нэрлэхэд энэ ялгаа далд үлддэг. Neon-д бичих боломжтой салбар эх өгөгдлийн төлөвийг авч эхэлдэг; Supabase-ийн ердийн preview branch бүтцээ авч, өгөгдлөө зориуд нэмүүлэх шаардлагатай. Иймээс branch үүсэх секундийг дангаар нь зэрэгцүүлэхээс өмнө тухайн хугацаанд ямар өгөгдөл бэлэн болсныг тогтоох нь чухал.

Реплика, нөөц хуулбар, сэргээх түүх

Унших реплика үндсэн сангаас уншилтын ачааллыг салгана. Өдөр тутмын нөөц хуулбар нь хадгалсан хувилбарыг сэргээхэд, харин PITR нь сонгосон мөчийн төлөвт буцахад зориулагддаг. Алдаатай migration эсвэл устгасан өгөгдлийн эрсдэлийг тооцоход реплика хурдан босохоос илүү сэргээх цонх, сэргээх аргын зардал чухал байж болно.

Neon-ийн instant restore нь хадгалсан өөрчлөлтийн түүхээр branch-ийг өмнөх төлөвт буцаадаг; түүхийг удаан хадгалах тусам ашигласан хадгалалтын төлбөр өснө. Supabase Pro-ийн өдөр тутмын нөөц хуулбар болон PITR нь өөр нөхцөлтэй үйлчилгээ. Production системд яг нэг мөчид буцах шаардлага байгаа бол зөвхөн багтсан нөөц хуулбарыг харьцуулж төсөв гаргах нь хангалтгүй.

Сарын төлбөрийг юугаар харьцуулах вэ

Supabase-ийн үнийн хүснэгтээр Pro сарын $25-аас эхэлж, төсөл бүрт 8 GB өгөгдлийн сангийн диск, төлөвлөгөөнд 250 GB egress, 100 GB файл хадгалалт, долоо хоног хадгалах өдөр тутмын нөөц хуулбар багтана; PITR нь долоо хоногийн сэргээх цонх тутамд сарын $100-ын нэмэлттэй. Branch-ийн ажиллах хугацаа мөн тусдаа тарифтай. Иймээс төлөвлөгөөний суурь үнэ нь олон preview орчин, нарийн сэргээх шаардлагатай төслийн эцсийн үнэ биш.

Neon-ийн Launch тарифын дагуу сарын суурь төлбөргүй бөгөөд compute-ийн CU-цаг $0.106, өгөгдлийн хадгалалт GB-сар тутамд $0.35, сэргээх түүхийн хадгалалт GB-сар тутамд $0.20; төсөлд зэрэг ажиллах 10 branch багтана. Идэвхгүй compute унтарч болох нь богино настай preview санд ашигтай. Харин branch-д өөрчлөлт хуримтлагдах, хадгалсан түүх уртсах, үйлдвэрлэлийн сан тогтмол ачаалалтай байх нь сарын дүнг өсгөнө.

Neon-ийн албан мэдэгдэлд 2026 оны зургадугаар сараас бүх төлбөртэй төлөвлөгөөний багтсан нийтийн өгөгдөл дамжуулалт сард 100 GB-аас 500 GB болсон гэжээ. Энэ квотыг Supabase Pro-ийн egress-тэй зэрэгцүүлж болох ч үйлчилгээ тус бүр юу хэмжиж, өөр ямар backend хэрэглээг төлбөрт оруулж байгааг хамт үзнэ. Дамжуулалтын багтаамж өндөр байлаа гээд compute, branch, Auth эсвэл Storage-ийн нийт зардал заавал бага болно гэсэн үг биш.

Auth, Storage хэрэгтэй үед сонголт өөрчлөгдөнө

Supabase нь Postgres-ийн хажуугаар Auth, Storage, Data API, Realtime болон Edge Functions-ийг нэг төслийн үйлчилгээ болгон өгдөг. Хэрэглэгч бүртгэл, файл байршуулах урсгал, өгөгдөлд суурилсан API-гаа хамтад нь эхлүүлэх багт энэ нь холбох ажлыг цөөлнө. Гэхдээ хэрэглэгчийн идэвх, файл хадгалалт, дамжуулалт өсөхөд багтсан квот болон нэмэлт төлбөр шийдвэрт орж ирнэ.

Neon ч зөвхөн Postgres санал болгодог үйлчилгээ байхаа больсон: Managed Better Auth, Object Storage, Functions болон AI Gateway нь түүний backend багцад орсон. Иймээс «backend эсвэл database» гэсэн ерөнхий шошгоор сонголтыг дуусгаж болохгүй. Багийн ашиглах нэвтрэлтийн урсгал, файлын хэрэгцээ, API-ийн шаардлага, preview салбар бүрт эдгээр үйлчилгээ хэрхэн ажиллахыг бодит хэрэглээтэй нь тулгах нь илүү зөв.

Гурван хэрэглээнд аль нь тохирох вэ

• MVP: Нэвтрэлт, файл хадгалалт, API, Realtime-ийг нэг төслөөс эхлүүлэх бол Supabase илүү шууд сонголт. Багтсан боломжууд нь эхний төсвийг ойлгомжтой болгоно; өгөгдөлтэй branch болон нарийн PITR хэрэгтэй бол нэмэлт төлбөрийг оруулна.
• Preview database: Өгөгдлийн бодит төлөвтэй, бичих боломжтой Postgres санг түр хугацаанд үүсгэх шаардлага давамгайлбал Neon давуу. Идэвхгүй compute унтрах боломжтой ч зэрэг ажиллах салбар, хуримтлагдсан өөрчлөлт, хадгалах хугацаа төлбөрт нөлөөлнө.
• Production backend: Auth, Storage, Data API болон Realtime-ийг нэг платформд төвлөрүүлэх багт Supabase тохирно. Эдгээр урсгалыг өөрөөр хэрэгжүүлсэн, харин өгөгдөлтэй branch болон унших репликаг өдөр тутмын ажиллагаандаа ашиглах багт Neon илүү тохирч болно.

Мөн уншаарай:

• GitHub Actions эсвэл GitLab CI: ижил pipeline 91 секундээр зөржээ
• PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө
• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө