SurrealDB 3.0 diperkenalkan dengan satu premis sederhana namun ambisius: satu basis data untuk semua model dan semua pola akses data. Di era aplikasi modern, data tidak lagi rapi dalam satu model tunggal. Dokumen bercampur dengan relasi, graf hubungan bertemu sinyal time series, vektor dipakai untuk semantic search, ditambah file dan event yang terus mengalir. Pendekatan tradisional biasanya menjahit 4–5 sistem spesialis sekaligus—NoSQL dokumen, RDBMS, graf database, time-series store, vector store—yang kemudian memunculkan latensi, kompleksitas operasional, dan celah konsistensi.
SurrealDB 3.0 mengambil jalur yang berbeda: CRDB (engine mereka) dijadikan mesin multimodel yang mampu mengelola relasional, graf, dokumen, time series, vector dan file dalam satu bahasa query, SurrealQL, dengan jaminan ACID. Dari sudut pandang pengembang, ini berarti lebih sedikit glue code, lebih sedikit komponen yang harus dipantau, dan “kepala” yang lebih lega saat merancang arsitektur.
Fondasi baru: stabilitas, performa, dan model data yang lebih bersih
Tim SurrealDB mengakui bahwa di versi 2.x, beberapa keputusan desain internal membuat mesin melakukan kerja yang tidak perlu dan menyulitkan prediktabilitas. Di 3.0, mereka “merapikan dapur” dengan beberapa langkah kunci:
Pertama, pemisahan tegas antara nilai (values) dan ekspresi (expressions). Pada versi sebelumnya, field bisa computed atau tidak, dan engine sering dipaksa menghitung terus menerus hanya untuk menampilkan hasil. Ini menambah evaluasi berulang, serialisasi ekstra, sekaligus memicu bug pinggir (edge cases) ketika logika disimpan di dalam record. Di 3.0, nilai dan ekspresi dipisah sehingga engine hanya mengeksekusi ekspresi ketika diperlukan, membuka jalan bagi query planner yang lebih prediktif dan optimasi yang lebih cerdas.
Kedua, mereka menghapus “futures” dan menggantinya dengan computed fields. Futures pada dasarnya adalah logika yang tertanam di setiap record dan dievaluasi per-baris. Pendekatan itu fleksibel tapi mahal, sulit di-scale, dan rentan perilaku tak terduga. Computed fields di 3.0 didefinisikan sekali di level schema dengan kata kunci computed, dan dievaluasi konsisten pada saat query. Logika terpusat, workload engine berkurang, dan pengalaman developer menjadi lebih mudah dipahami. Guardrail juga lebih jelas: hanya bisa di top-level field dan tidak bisa dikombinasikan dengan value, default, atau assert. Artinya, SurrealDB mencoba memaksa “good practices” langsung dari level schema.
Ketiga, mereka memindahkan katalog inti (namespace, database, index) dari penyimpanan berbasis nama ke ID berbasis bilangan bulat tetap. Kuncinya lebih kecil dan konsisten di disk, lookup lebih cepat, dan resource bisa di-rename tanpa memutus referensi. Dampak praktisnya mungkin terasa “infra banget”, tapi untuk deployment besar, ini mengurangi storage dan I/O sekaligus mempermudah evolusi nama skema dan database.
Keempat, “synced writes” kini menjadi default. Alih-alih mengandalkan OS untuk flush data kapan saja, SurrealDB hanya mengonfirmasi write setelah benar-benar durabel di disk. Ini tidak mengubah kemampuan, tapi membuat perilaku aman jadi standar. Buat beban produksi yang sensitif terhadap kehilangan data, pilihan default ini penting.
Kelima, SurrealDB mendesain ulang representasi dokumen di disk. Record value dan metadata kini disimpan terpisah di dalam “document wrapper” sehingga tidak lagi ada field tersembunyi yang membuat hasil query kotor dan statistik tabel berperilaku aneh. Dengan metadata sistem yang dapat disuntikkan tanpa “mengotori” data pengguna (misalnya timestamp atau version stamp), fondasi ini menyiapkan fitur-fitur manajemen data yang lebih kaya ke depan.
Menariknya, semua ini diiringi effort bugfix yang agresif: lebih dari 40 isu sudah diselesaikan dan 80+ diprioritaskan untuk siklus rilis ini. Go dan Java SDK sekaligus mencapai status 1.0 sehingga integrasi di ekosistem populer lebih terasa “production-ready”, bukan sekadar eksperimen.
Indexing generasi baru: dari full-table scan ke index-aware planner
Di dunia database, index sering jadi pembeda antara sistem yang “cukup” dan sistem yang benar-benar usable di skala besar. Versi sebelum 3.0 sering terpaksa melakukan full-table scan karena planner belum bisa mengeksploitasi index majemuk (compound) dan index descending secara optimal. Full-text search hanya mendukung pencarian yang mengandung semua term (AND), dan update index berjalan single-threaded—gabungan faktor yang membuat query berat terasa lambat dan menyulitkan workload tinggi.
SurrealDB 3.0 merombak itu dengan fondasi indexing baru. Indexing kini menggabungkan log-based multi-writer engine, format key yang dinormalisasi, dan planner yang lebih cerdas. Index compound dapat menangani prefix equality dan range query dalam satu rencana eksekusi: query dengan filter pada “prefix” dan rentang di kolom kedua bisa dijawab langsung dari index tanpa menyentuh seluruh tabel, bahkan pada dataset jutaan baris. Di sisi lain, ORDER BY DESC bisa dilayani langsung menggunakan index pada backend yang mendukung, menghindari sort di memori.
Untuk nilai numerik, encoding canonical diperkenalkan—integer 0, float 0.0, dan decimal 0 diperlakukan sama dalam constraint unik dan operasi scan. Ini menyederhanakan ekspektasi developer: equality dan ordering pada angka bekerja konsisten tanpa kejutan tipe data.
Full-text indexing juga ditingkatkan. Kini mendukung operasi boolean penuh (bukan hanya “semua term harus muncul”), dan update index dapat dilakukan oleh banyak writer secara concurrent dengan log-based indexing dan background compaction. Index creation besar tidak lagi dibuat dalam satu transaksi raksasa, melainkan dibangun secara batch-concurrent, mengurangi risiko kehabisan memori atau ruang file. Dampak kombinasi ini sangat nyata: beralih dari O(table scan) ke O(index lookup) menurunkan latensi dari detik ke milidetik untuk tabel jutaan baris, sekaligus menghapus bottleneck write pada full-text search.
Dari perspektif redaksi dan arsitektur, langkah ini mengirim sinyal bahwa SurrealDB ingin bersaing serius bukan hanya pada fitur “AI-ready”, tetapi pada hal paling membosankan namun kritis: performa dasar index dan planner.
Client-side transactions: logika bisnis di aplikasi, konsistensi di database
Sebelum 3.0, transaksi di SurrealDB ditangani dalam satu permintaan. Banyak skenario yang cukup dengan pola ini, tetapi ada trade-off besar: setiap logika keputusan—apakah commit atau cancel—harus ditulis langsung di dalam SurrealQL. Hal ini mendorong developer untuk menumpuk logika bisnis ke layer query, bukan ke bahasa pemrograman utama.
Di 3.0, diperkenalkan client-side transactions. Developer dapat:
- memulai transaksi,
- menambahkan beberapa operasi lintas permintaan,
- lalu commit atau cancel ketika sudah yakin,
dengan tetap mempertahankan jaminan ACID yang kuat. Pola kerja ini mengikuti alur Begin → add operations → Commit/Cancel, namun logika bisa sepenuhnya berada di Rust, Go, atau JavaScript melalui SDK. Hasilnya, alur bisnis multi-step menjadi lebih natural ditulis di application layer, tapi tetap terlindungi oleh transactional safety di database.
Implikasinya bagi pengembang cukup besar: kode jadi lebih mudah dibaca, lebih mudah di-debug, dan lebih mudah diuji. Untuk sistem dengan proses panjang (misalnya butuh input manusia di tengah), client-side transaction ini membuka peluang pola transaksi yang lebih kaya tanpa perlu merakit solusi kompensasi manual yang rumit.
In-memory storage engine: ultra-low latency dengan ACID penuh
Bagi aplikasi yang kritis terhadap performa, SurrealDB 3.0 memperkenalkan in-memory storage engine baru di samping SurrealKV. Engine ini menyimpan data di memori untuk read-write super cepat, namun tetap menyediakan persistence asinkron ke disk melalui append-only log. Yang menarik, engine ini tidak sekadar “cache plus flush”, tetapi dirancang dengan arsitektur transaksi modern:
- Dua komponen inti, transaction commit queue dan transaction merge queue, memastikan setiap transaksi mendapatkan global order dengan timestamp commit yang terurut dan diterapkan secara atomik dan incremental ke state bersama.
- Model multi-version concurrency control (MVCC) digunakan agar setiap write menghasilkan versi immutable baru. Transaksi membaca snapshot konsisten tanpa saling mengunci. Ini memungkinkan pembacaan snapshot historis (time travel queries) berdasarkan commit timestamp—berguna untuk audit, debugging, dan analitik temporal.
- Konflik antar transaksi dideteksi secara deterministik, terukur, dan paralel, dengan memanfaatkan metadata ringan untuk melacak dependensi.
Hasil akhirnya adalah engine in-memory yang mendukung multi-table, multi-row transaction dengan isolation level serializable tanpa mengandalkan locking berat. Banyak transaksi dapat berjalan paralel tanpa kontensi tinggi, namun tetap menjaga correctness. Untuk skenario real-time analytics, low-latency API, maupun event processing yang kompleks, kombinasi in-memory + ACID + MVCC + time travel ini menjadikan SurrealDB 3.0 kandidat menarik dibanding sekadar menyambungkan cache eksternal ke database tradisional.
Secara editorial, ini adalah salah satu bagian paling ambisius: SurrealDB ingin memadukan kecepatan in-memory system dengan kejujuran model data relational yang ketat. Jika implementasi nyatanya stabil, ini bisa mengurangi kebutuhan sistem terpisah seperti Redis + PostgreSQL pada beberapa use case.
Computed fields dan record references: skema yang lebih ekspresif dan mudah dirawat
Di bagian tengah video, tim memperlihatkan bagaimana computed fields dan record references bekerja pada contoh sederhana: model lisensi mengemudi yang berlaku dua tahun sejak diterbitkan.
Dengan computed fields, field valid cukup didefinisikan sekali di schema untuk mengecek apakah lisensi masih kurang dari dua tahun. Tidak ada proses update manual atau reset. Setiap query ke record lisensi akan otomatis mengembalikan valid yang dihitung on the fly. Untuk pengembang, ini mengurangi risiko ketidakonsistenan antara data aktual dan derived data.
Record references memperkaya ini dengan membuat relasi dua arah yang dideklarasikan di level schema. Sebelumnya, relasi menggunakan link satu arah yang mendorong pengembang menyusun query ad-hoc untuk melihat “kebalikan” relasi. Di 3.0, field bertipe reference memungkinkan record yang dilink untuk secara otomatis mengenali incoming link, dan query bisa menelusuri hubungan ini dengan sintaks mirip graf, menggunakan panah tilde ~>. Pada contoh, seseorang bernama Billy dengan dua lisensi bisa di-query satu kali untuk mengembalikan semua lisensi miliknya beserta status valid masing-masing, tanpa join manual berulang.
Di proyek nyata—seperti portal berita, sistem membership, atau platform social—kombinasi computed fields dan record references akan mempermudah modeling data: relasi terasa alamiah, traversal lebih singkat, dan performa lebih terjaga karena database mengerti struktur hubungan sejak awal.
Native file support tahap awal: file sebagai warga kelas satu
SurrealDB sebelumnya mendorong pengguna menyimpan file di luar (object storage, dsb.) dan hanya menaruh path di database. Di 3.0, mereka memperkenalkan tahap awal native file support lewat konsep “bucket” dan “file pointer”.
Admin dapat mendefinisikan bucket—lokasi fisik atau penyimpanan in-memory—dengan satu pernyataan DEFINE BUCKET. Setelah bucket ada, pointer file berupa string berawalan f dapat digunakan untuk meng-put byte, get isi, rename, dan head untuk melihat metadata. Konversi tipe untuk bytes juga ditingkatkan: bisa di-cast ke array angka, string, atau string_lossy untuk menangani byte yang bukan UTF-8 valid tanpa error fatal.
Bagi aplikasi yang membutuhkan penyimpanan file ringan atau embedded assets (misalnya thumbnail, konfigurasi biner, atau attachment kecil), integrasi ini mengurangi kerumitan sinkronisasi antara database dan storage eksternal. Namun untuk skala besar, ini sepertinya baru langkah pertama menuju sistem file yang lebih canggih, bukan pengganti object storage sepenuhnya.
Define API: layer API langsung di dalam database
Salah satu fitur yang cukup berani adalah DEFINE API, yang pada dasarnya memasukkan kemampuan mendefinisikan endpoint HTTP dan middleware langsung di dalam bahasa SurrealQL. Dengan flag deny arbitrary query, admin bisa memaksa grup tertentu (misalnya guest) hanya boleh mengakses data melalui endpoint yang sudah didefinisikan, bukan query bebas.
Dalam contoh video, mereka mendefinisikan endpoint GET /api/namespace/database/get-latest untuk mengembalikan komentar 10 menit terakhir, dan menambahkan middleware:
api::timeoutuntuk membatasi waktu server (misalnya 50 ms),api::request::max_bodyuntuk membatasi ukuran request body (misalnya 250 byte).
Endpoint dapat di-invoke dari dalam database dengan fungsi khusus, atau dari luar menggunakan tool seperti curl. Ada juga DEFINE CONFIG untuk mengatur middleware level-database, lalu DEFINE API dapat menambah atau menimpa konfigurasi tersebut.
Dari perspektif arsitektur, ini menarik sekaligus kontroversial. Di satu sisi, menghilangkan lapisan service kecil hanya untuk “read-only API sederhana” dapat memangkas kompleksitas. Rate limiting dasar, keamanan, dan query sudah ada di satu tempat. Di sisi lain, menyatukan data access dan API behavior di database memperkuat pola “fat database, thin app”, yang jika tidak dikelola hati-hati bisa membuat tim back-end kesulitan memisahkan concern. Namun untuk tim kecil atau sistem internal, ini bisa menjadi jalan pintas yang sangat produktif.
Surrealism: plugin WebAssembly dan integrasi AI di lapisan data
Bagian penutup video memperkenalkan Surrealism, sistem plugin open-source yang memberi “true extensibility inside the database itself”. Plugin ditulis sebagai fungsi Rust (bahkan ke depan JavaScript dan Python), dikompilasi ke WebAssembly, lalu dieksekusi di dalam database dengan sandbox yang deterministik dan terisolasi namun mendekati performa native.
Plugin dapat:
- dimuat dari disk lokal, object storage, atau di-upload ke SurrealDB,
- diaktifkan dan dijalankan tanpa restart database,
- dilindungi dengan kontrol izin granular.
Pada level pengalaman developer, plugin dikelola seperti modul biasa: ada metadata di file TOML, bisa dites dengan testing framework Rust, diintegrasikan ke pipeline CI/CD, dan di-versioning seperti komponen lain di aplikasi.
Yang membuat Surrealism relevan dengan tren sekarang adalah integrasi AI. Plugin dapat:
- berinteraksi dengan runtime inferensi berakselerasi GPU secara lokal,
- memanggil API eksternal untuk text/image generation, klasifikasi, embedding, translasi, dan lainnya,
- memiliki akses penuh ke engine query, schema, dan file API baru.
Contoh skenarionya: satu plugin dapat mentranskripsi audio, melakukan named-entity extraction, memperkaya hasil dengan model remote, lalu menyimpan output dalam satu transaksi. Atau plugin yang memanggil LLM lokal untuk memproses input pengguna dan menyimpan hasil transformasi sebagai field tertentu. Semua ini terjadi di dalam SurrealDB, tanpa harus “mendorong” data keluar ke service tambahan, lalu kembali lagi.
Tim SurrealDB menyebut pola ini sebagai “datagentic workflow”: logika dan alur kerja agentic dibawa ke dekat data, bukan sebaliknya. Jika digarap serius, pendekatan ini bisa mengurangi tumpukan service glue di aplikasi AI modern: pipeline ETL, job worker, microservice tambahan bisa diserap menjadi plugin transaksional di database.
Namun di sisi lain, membawa AI dan logika berat langsung ke database juga membawa risiko: resource contention (CPU/GPU), kompleksitas debugging, hingga potensi vendor lock-in ke ekosistem plugin mereka. Di sini peran desain sandbox WebAssembly dan observability akan menjadi kunci; tanpa hal itu, “database yang bisa segalanya” mungkin justru sulit dioperasikan.
Refleksi: kemana arah SurrealDB 3.0?
Dari sudut pandang redaksi dan pengamat teknologi, SurrealDB 3.0 bukan sekadar menambah fitur—ini adalah pernyataan arah. Mereka ingin menjadi:
- single source of truth untuk aplikasi modern,
- multimodel dan multimodal secara desain,
- cukup cepat untuk real-time,
- cukup fleksibel untuk berevolusi bersama pola AI dan agent yang terus berubah.
Di satu sisi, ini menjawab rasa frustasi banyak tim engineering yang selama ini merangkai Postgres + Redis + Elastic + Vector DB + storage + API gateway menjadi satu arsitektur yang rentan. Di sisi lain, pendekatan “all-in-one” pada tataran database selalu membawa pertanyaan klasik: seberapa baik satu sistem bisa menggantikan spesialis-spesialis tadi di skala besar, dan seperti apa trade-off operasionalnya.
Yang jelas, dengan SurrealDB 3.0, diskusi tentang “di mana sebaiknya logika dan AI tinggal—di aplikasi atau di database?” akan semakin menarik. Untuk banyak tim, terutama yang mengejar kecepatan iterasi di produk AI-first, tawaran “multimodel, ACID, plugin AI, file, API, dan in-memory engine dalam satu paket” adalah sesuatu yang layak dicoba secara serius di proyek berikutnya.