1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Turso ने Rust-आधारित डेटाबेस core से Postgres-compatible frontend जोड़कर इसे डेटाबेस के LLVM जैसी संरचना में विस्तारित किया है, जहाँ एक ही execution engine कई database languages को संभालता है
  • Postgres SQL को common AST में parse कर VDBE bytecode में compile किया जाता है; feasibility साबित करने वाले pgmicro को main code tree में merge कर official development base बनाया गया
  • मौजूदा core SQLite file compatibility, MVCC concurrent writes, asynchronous execution, समृद्ध type system और auto-refreshing materialized views को support करता है, और कई testing techniques से reliability verify करता है
  • इसे browser, mobile और तरह-तरह के devices पर embedded या single file के रूप में चलाने के लिए design किया गया है, साथ ही existing applications, ORM और psql Postgres wire protocol से connect कर सकें
  • 100% समानता के बजाय व्यापक रूप से इस्तेमाल होने वाले core features पर focus है, ताकि ज्यादातर existing applications बिना modification चल सकें; extensions और PL/pgSQL के लिए WASM और compatibility layer लागू करने पर विचार किया जा रहा है, और development MIT license के तहत है

Postgres को Turso के ऊपर बनाने की वजह

  • Turso Rust में लिखा गया एक modern database core है, और इसके ऊपर शुरुआत से Postgres-compatible database बनाया जा रहा है
  • long-term goal मौजूदा Postgres को बस Rust में port करना नहीं, बल्कि modern architecture वाला नया database बनाना है
    • हर connection के लिए अलग process इस्तेमाल नहीं करता
    • browser के अंदर embedded तरीके से चल सकता है
    • एक database को single file के रूप में handle कर सकता है
    • materialized views बिना अलग job के automatically refresh होती हैं
  • लक्ष्य एक stable core से कई frontends जोड़ने वाला replaceable compilation structure बनाना है
    • SQLite पहला frontend है
    • Postgres अगला official frontend है
    • भविष्य में MySQL, Redis, experimental databases जैसे frontends भी जोड़े जा सकते हैं
  • मौजूदा result finished product नहीं, बल्कि वास्तव में चलाया जा सकने वाला development base stage है

SQLite reimplementation से common database core तक

  • Turso मूल रूप से SQLite को Rust और modern architecture में पूरी तरह reimplement करने वाला project था, और SQLite files खोलने व बनाने की file compatibility बनाए रखता है
  • इसमें SQLite के दायरे से आगे की capabilities भी पहले से मौजूद हैं
    • Postgres की तरह MVCC का उपयोग करके concurrent writes support करता है
    • Postgres जैसा समृद्ध type system देता है
    • पूरी तरह asynchronous तरीके से काम करता है, इसलिए browser जैसे constrained environments में भी native execution के लिए suitable है
    • materialized views real time में automatically refresh होती हैं, इसलिए REFRESH MATERIALIZED VIEW cron jobs या trigger combinations की जरूरत नहीं होती
  • Postgres frontend जुड़ने पर भी existing Turso और SQLite के goals नहीं बदलेंगे
    • SQLite की full compatibility और future workloads के लिए feature expansion पर काम जारी रहेगा
    • जरूरी features implement करते समय Postgres tests का भी उपयोग हो सकेगा, जिससे development speed बढ़ सकती है

Reliability और open contribution model

  • SQLite जैसी मजबूती reproduce करने के लिए reliability को product feature माना जाता है
    • deterministic simulation testing का इस्तेमाल होता है
    • Antithesis testing की जाती है
    • Oracle testing, fuzzing और formal techniques भी साथ में लागू की जाती हैं
  • Turso में फिलहाल 260 से ज्यादा contributors हैं, और outsiders भी project direction में भाग ले सकें, इसके लिए Open Contribution approach चलाया जाता है
  • code और high quality standards को केंद्र में रखते हुए, लगातार काम करने वाले contributors को project decision-making में भी शामिल करने वाला Linux kernel-style environment लक्ष्य है
  • AI द्वारा लिखे contributions भी स्वीकार किए जाते हैं, लेकिन उनमें पर्याप्त quality होनी चाहिए; इंसानों को code का thorough review करना और architecture समझना जरूरी है

SQLite के अंदर VDBE virtual machine

  • SQLite SQL को direct execute करने वाली single layer नहीं है; यह SQLite dialect के SQL को VDBE bytecode में compile करके execute करने वाला virtual machine structure रखता है
  • VDBE JVM, .NET, WASM जैसा general-purpose bytecode नहीं है, बल्कि B-tree में item ढूँढना जैसे database-specific high-level operations देता है
  • इस bytecode language की कोई externally published specification या modular interface नहीं है, लेकिन यह SQLite के अंदर सचमुच मौजूद है, और Turso भी वही design अपनाता है
  • Turso VDBE की generality verify करने के लिए एक छोटे C-to-VDBE compiler से Doom को convert किया गया
    • actual Turso engine को WASM में compile कर browser tab में Doom का VDBE bytecode execute किया गया
    • database जिस तरह SELECT process करता है, उसी तरह Doom चलाया गया
    • हर frame को एक result row के रूप में process किया गया
    • memory regions को readable और writable blobs के रूप में represent किया गया
    • implementation turso-vdbe-doom-example repository में देखा जा सकता है

Postgres frontend की compilation structure

  • SQLite और Postgres को जोड़ने की पिछली कोशिशें SQLite के monolithic structure के कारण मुख्यतः Postgres queries को SQLite queries में बदलने वाले query-layer translation पर निर्भर थीं, और दोनों databases के external behavior में differences के कारण impedance mismatch बड़ा था
  • internally, ज्यादातर SQL databases B-tree और indexes के set के इर्द-गिर्द similar basic operations करते हैं
  • Postgres और SQLite के storage structures में स्पष्ट differences हैं
    • Postgres rows को heap file में रखता है और separate B-tree indexes, tuple versions, TID और vacuum का इस्तेमाल करता है
    • SQLite data को B-tree में cluster करता है
  • ये differences मुख्यतः disk पर bytes को arrange करने के तरीके से आते हैं, और Postgres के लिए जरूरी operations को existing VDBE से represent किया जा सकता है या VDBE commands extend करके support किया जा सकता है
  • नई structure में database frontend replace किया जा सकता है
    1. Postgres language को common AST में parse किया जाता है
    2. AST को Turso bytecode में compile किया जाता है
    3. common Turso core bytecode execute करता है
  • feasibility verify करने वाला early experiment pgmicro से किया गया था, और result को Turso main code tree में merge कर official project में बदल दिया गया

Execution forms और use cases

  • goal एक ही Postgres SQL और database behavior को server के बिना कई forms में provide करना है
    • browser tab में actual Postgres-compatible database चलाना
    • agents हर user के लिए नया database बनाएं और हर एक को single file के रूप में manage करें
    • local-first applications Postgres data को single file के रूप में download करें और फिर वापस sync करें
    • mobile phones और तरह-तरह के devices पर SQLite की तरह embedded तरीके से चलाना
  • existing Turso database को local file में sync करने की capability भी Turso/Postgres में support करने की योजना है
  • single-file और embedded execution के अलावा इसमें wire protocol और server implementation भी शामिल होंगे, ताकि existing applications, ORM और psql connect कर सकें
  • निकट भविष्य में Turso team द्वारा directly develop किए जाने वाले official frontends SQLite और Postgres होंगे, और structure को ऐसा open रखा जाएगा कि external contributors दूसरे frontends बना सकें

वर्तमान run method और participation

  • अभी कोई released package नहीं है, लेकिन source से directly build और run किया जा सकता है
    cd postgres/cli && cargo run
    
  • Postgres frontend अलग repository नहीं है; यह पहले दिन से Turso code tree के अंदर official frontend के रूप में develop हो रहा है
  • development और contribution Turso GitHub repository में होते हैं

Compatibility के goals और boundaries

  • SQLite से कहीं ज्यादा complex Postgres की nature के कारण 100% compatibility को mandatory goal नहीं माना गया है
  • focus core और widely used features को पर्याप्त support करने पर है, ताकि ज्यादातर users अपनी applications बिना modify किए चला सकें
  • जब modern features और perfect 1:1 compatibility टकराते हैं, तो feature-by-feature निर्णय लिया जाएगा
    • Turso की materialized views real-time auto-refreshing method पर आधारित हैं
    • सिर्फ full compatibility के लिए non-auto-refreshing legacy method को अलग से implement किया जाएगा या नहीं, यह तय नहीं है
  • जैसे-जैसे feature scope बढ़ेगा, Turso/Postgres Postgres की copy से ज्यादा independent database जैसा बन सकता है

AI usage और development speed

  • AI tools का सक्रिय रूप से उपयोग किया जाता है, लेकिन code review और architecture understanding को skip नहीं किया जाता
  • database जैसे important components में माना जाता है कि AI tools अभी verification responsibility को replace करने के स्तर तक नहीं पहुँचे हैं
  • Fable को 24 घंटे चलाने वाली approach की तुलना में per-commit speed धीमी हो सकती है, लेकिन शुरुआत ऐसे database core से होती है जो पहले से काम कर रहा है और widely tested है
  • तेजी से changes करके system तोड़ने के बजाय धीमा सही, लेकिन सही implementation चुना गया है
  • सभी features पूरा करने में समय लगेगा, और कुछ features को suitable architecture बनने तक लंबी development process से गुजरना होगा

PL/pgSQL और extensions

  • PL/pgSQL कोई unimplementable चीज नहीं, बल्कि procedural language है; लेकिन उसे उसी तरह reimplement करने के बजाय separate procedural language और compatibility layer देने की संभावना ज्यादा है
  • कुछ Postgres extensions को WASM container से load करने का proof of concept मिल चुका है
    • जो extensions सिर्फ WASM container द्वारा provide किए गए symbols का इस्तेमाल करते हैं, उन्हें arbitrary तरीके से load किया जा सकता है
    • WASM execution से performance loss होता है
    • यह अभी final design के रूप में तय नहीं है
  • ऐसा extension system जो arbitrary code को बिना limit execute करने दे, desirable नहीं माना जाता
  • कुछ extensions support नहीं हो सकते, लेकिन माना जा रहा है कि कई extensions को WASM में compile करने पर load किया जा सकेगा

Expected timeline और open-source strategy

  • शुरुआत से नया database बनाने के बजाय, ऐसे core से शुरुआत की जा रही है जो पहले से काम करता है, tested है और Postgres के साथ internal structure का काफी हिस्सा share करता है
  • सभी Postgres features implement करने में लंबा समय लग सकता है, लेकिन practical use के लिए useful काफी बड़ा feature subset कुछ महीनों में provide किया जा सकता है, ऐसा अनुमान है
  • दो core developers अभी करीब 44 साल के हैं और अगले कम से कम 20 साल तक develop कर सकते हैं, इसलिए full feature completion में जल्दबाजी नहीं है
  • actual development speed और scope community contributions पर काफी निर्भर करेंगे
    • SQLite dialect में multi-process support के समय team के पास Windows machine नहीं थी, इसलिए Windows implementation बाहर रखा गया
    • Turso का बहुत इस्तेमाल करने वाले एक external developer ने रुचि ली और एक हफ्ते के अंदर Windows support पूरा कर दिया
  • experimental frontends code tree के बाहर develop किए जा सकते हैं, लेकिन official Postgres frontend पर existing Turso जैसा ही MIT license लागू होगा

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की रायें
  • लगता है लगभग सभी SQL डेटाबेस queries को virtual machine (VM) के लिए compile करते हैं
    इस लिहाज़ से सिर्फ SQLite को अलग से खास बताना थोड़ा अजीब लगता है

    • ज़्यादातर डेटाबेस relational operation tree बनाते हैं और हर operation में push या pull interface रखते हैं
      वहीं SQLite queries को variables और loops वाले imperative bytecode में compile करता है
  • pgwire developer के तौर पर खुशी है कि Turso PostgreSQL-compatible database में pgwire को फिर से इस्तेमाल कर रहा है

  • जिज्ञासा है कि कंपनी को क्यों लगा कि direction change की ज़रूरत है

  • जिज्ञासा है कि उन्होंने SQLite reimplementation पूरा कर लिया है, या उसे छोड़ दिया है
    https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next

    • https://github.com/tursodatabase/turso/…
      लगता है वे अभी भी उस लक्ष्य को बनाए रखते हुए बीच में दूसरे frontend भी जोड़ रहे हैं
  • यह बेहद दिलचस्प लेख है, और इसे अनुचित तरीके से flag किया जाना शर्मनाक है

    • यह इतनी high-impact technology है कि किसी दिन मेरे work project का खेल बदल सकती है
      यह कतई “off-topic” या “spam” नहीं है, इसलिए बिल्कुल समझ नहीं आता कि इसे इस तरह flag क्यों किया गया
      शायद article में एक dash होने भर से इसे AI garbage मान लिया गया हो; लगता है लोग सचमुच होश खोते जा रहे हैं
      इस site की flagging culture बहुत खराब हो गई है, इसलिए moderators को कार्रवाई करनी चाहिए। दुर्भावना से flag करने वाले कुछ लोगों को block कर दिया जाए तो शायद बाकी भी संयम बरतें
    • अब तो अनुचित flagging खुद यहां की culture बन चुकी है
  • मैं पहले से Turso के SQLite का successor होने का दिखावा करने वाले रवैये से असहज रहा हूं, और इसी वजह से कुछ साल पहले तय कर लिया था कि उनका software बिल्कुल इस्तेमाल नहीं करूंगा
    लेकिन अगर वे SQL Server के बाहर भी तेज़ और सस्ते automatically refreshing materialized views देते हैं, तो शायद अंततः मुझे इसे इस्तेमाल करना पड़ जाए