Parser SQL 70 Kali Lebih Cepat yang Dibuat Hampir Tanpa Melihat Kode

• PostHog menulis ulang parser SQL C++ berbasis ANTLR melalui beberapa sesi Claude Code, menghasilkan parser Rust 16 ribu baris, alat 5 ribu baris, dan ribuan baris pengujian, serta memperoleh peningkatan kecepatan sekitar 70 kali di laptop
• Implementasi baru berpusat pada predictive recursive descent parser dan inti ekspresi Pratt, dengan lookahead terbatas dan backtracking spekulatif hanya di tempat yang diperlukan, sehingga menghilangkan biaya traversal graf umum milik ANTLR
• Dengan parser C++ lama sebagai implementasi acuan, mereka menggabungkan property-based testing, kueri nyata yang dianonimkan, regression test, pembuatan berbasis code coverage, dan reduksi ShrinkRay untuk secara berulang menghilangkan ketidaksesuaian antara kedua parser
• Dalam mode shadow produksi, hasil parsing jutaan kali tidak pernah berbeda dari parser lama, sehingga trafik dialihkan hanya dalam beberapa jam, dan mencatat peningkatan kecepatan rata-rata 454 kali di produksi
• Pendekatan ketika parser generator menyediakan grammar dan implementasi acuan, sementara LLM memverifikasi kesetaraan melalui fuzzing, menunjukkan kemungkinan memangkas pengembangan parser berperforma tinggi yang sebelumnya membutuhkan keahlian khusus dan berbulan-bulan kerja menjadi hanya beberapa hari

---

Mengapa PostHog Membutuhkan Parser SQL

• PostHog mengubah SQL masukan menjadi SQL ClickHouse mentah agar pengguna dapat mengakses data secara langsung dengan SQL
  • Menyediakan tampilan data logis yang independen dari tata letak fisik database
  • Melindungi kueri lama agar tidak rusak saat lapisan database diubah
  • Menambahkan optimisasi performa dan kontrol akses dalam proses transformasi
• Sebagian besar alat PostHog, seperti product analytics, session replay, dan error tracking, juga melewatkan kueri yang ditulis dalam SQL melalui proses transformasi yang sama
• Untuk mentransformasi SQL, pertama-tama SQL harus diubah menjadi abstract syntax tree (AST), lalu tree ini diubah kembali menjadi SQL ClickHouse
• Parser adalah komponen pertama yang memproses masukan kueri yang tidak tepercaya
  • Kontrol akses dan optimisasi setelahnya juga semuanya bergantung pada tree yang dibuat parser

Struktur dan Biaya Parser ANTLR Lama

• Sebelum era AI coding, menulis dan memelihara parser secara langsung sangat sulit, sehingga PostHog menggunakan parser generator open source ANTLR
• Jika grammar diberikan sebagai file .g4 deklaratif, ANTLR menghasilkan sebagian besar kode parser
• Parser lama juga sudah dihasilkan dalam C++, jadi peningkatan performa kali ini bukan sekadar hasil mengganti bahasa implementasi ke Rust
• ANTLR kuat dan fleksibel, tetapi membutuhkan lebih banyak pekerjaan saat memproses tiap token
  • Grammar dikompilasi menjadi bentuk yang mirip augmented transition network (ATN), yaitu nondeterministic finite automaton (NFA) dengan stack
  • Saat runtime, interpreter umum menelusuri graf ini
  • Alih-alih fungsi yang ditulis langsung seperti parseExpression(), ia melewati lapisan abstraksi dan indirect call tambahan
• Karena lookahead dinamis arbitrer juga didukung, jika ada beberapa alternatif, semua interpretasi disimulasikan bersamaan sampai hanya satu yang tetap valid
• Bahkan ANTLR yang cukup teroptimisasi pun, dengan struktur interpreter traversal graf, sulit menjadi lebih cepat daripada recursive descent parser yang diimplementasikan langsung

Mencoba Dua Implementasi Parser Secara Paralel

• Dengan AI, menulis dan memelihara parser yang diimplementasikan langsung menjadi lebih mudah, tetapi sekadar meminta Claude membuat parser Rust tanpa kesalahan tidaklah cukup
  • Claude membuat banyak kesalahan
  • Berulang kali meragukan apakah penulisan ulang itu sendiri memungkinkan
  • Cenderung ingin mengakhiri pekerjaan pada akhir setiap putaran coding
• Dalam beberapa sesi Claude Code yang berjalan lama, dua pendekatan diuji secara paralel
  • Pendekatan berfokus performa menggunakan recursive descent parser dan loop ekspresi Pratt, lalu menambahkan lookahead dan backtracking hanya di tempat yang diperlukan
  • Pendekatan berfokus peluang keberhasilan mengikuti perilaku ANTLR semaksimal mungkin, tetapi mengimplementasikan transisi sebagai kode eksplisit alih-alih traversal graf umum
• Kedua pendekatan akhirnya bekerja pada tingkat yang mirip, tetapi perlu beberapa hari untuk memastikannya
• Tujuannya adalah benar-benar cocok dengan parser C++ lama untuk semua kueri realistis, dan menghasilkan hasil sedekat mungkin bahkan untuk kueri artifisial
  • SQL yang terlihat tidak normal tetapi valid seperti SELECT SELECT FROM FROM WHERE WHERE AND AND juga dimasukkan sebagai target pengujian
• Parser C++ lama dijadikan implementasi acuan (oracle), lalu pengembangan dilakukan dengan pendekatan test-driven: mencari SQL yang diproses berbeda, memperbaiki parser baru, dan membandingkannya lagi

Menghasilkan Ketidaksesuaian dengan Property-Based Testing

• Setelah terlebih dahulu meloloskan regression test yang terkumpul selama pengembangan parser lama, ketidaksesuaian baru dihasilkan secara sistematis
• Dalam property-based testing (PBT) menggunakan Hypothesis, properti verifikasi didefinisikan sebagai “parser baru cocok dengan implementasi acuan”
  • Nilai inputnya adalah kueri SQL
  • Hypothesis mencari kueri yang membuat hasil kedua parser tidak cocok
• Untuk menghasilkan SQL yang menarik, mereka bersama Claude membuat alat yang menghasilkan kode generator SQL dari file grammar ANTLR
  • Parser terpisah yang membaca file .g4 itu sendiri juga ditulis
  • Setelah itu, transformasi seperti pertukaran token atau penambahan tanda kurung dimasukkan ke tahap pembuatan

Susunan Prompt untuk Mencegah Perbaikan yang Rapuh

• PBT secara stabil menghasilkan pengujian baru, tetapi Claude berulang kali melakukan perbaikan rapuh, misalnya memperbaiki kasus tertentu dengan lookahead satu token lalu kemudian menemukan bahwa lookahead dua token diperlukan
• Ada kemungkinan, saat jendela konteks sering penuh dan dikompresi, Claude memperbaiki dalam kondisi sudah melupakan grammar sebenarnya atau perilaku parser acuan
• Masalah ini dikurangi dengan menginstruksikan agar tepat sebelum menulis kode untuk memperbaiki setiap ketidaksesuaian, file grammar terkait dan seluruh kode sumber C++ dimuat ke dalam konteks

Menjalankan CPU dan Claude Terus-Menerus Secara Bersamaan

• PBT terus berjalan di latar belakang, mencatat kasus gagal ke file, dan alat dikonfigurasi agar Claude mengambil kasus tersebut saat tidak ada pekerjaan lain
• Kasus gagal dikumpulkan dari beberapa jalur
  • Regression test lama
  • SQL yang dihasilkan PBT
  • Kueri anonim dari log kueri produksi
  • Kasus yang dibuat dengan meminta agen latar belakang untuk “memikirkan edge case dengan benar-benar mendalam”
• Dua parser yang dikembangkan secara paralel berbagi kumpulan regression test, sehingga kegagalan yang ditemukan dalam satu sesi langsung tercermin juga pada sesi lain
• Hypothesis dapat mengecilkan kasus yang dibuatnya sendiri menjadi reproduksi minimal, tetapi tidak dapat diterapkan pada SQL eksternal, sehingga ShrinkRay digunakan untuk kasus tersebut
• Setelah itu, pembuatan pengujian yang dipandu code coverage juga ditambahkan
  • Komponen SQL yang belum pernah dieksekusi dideteksi, lalu pembuatan dibiasakan agar struktur tersebut lebih sering muncul
  • Ini tidak esensial untuk mencapai akurasi 100% pada kumpulan kueri produksi, tetapi membantu menemukan kasus yang sangat subtil

Proses Iteratif Otomatis untuk Menemukan dan Memperbaiki Kegagalan

• Loop pengembangan akhir secara otonom mengulang langkah-langkah berikut
  1. Menghasilkan kegagalan baru lewat PBT, kumpulan kueri nyata, regression test, dan eksplorasi edge case
  2. Mengecilkan kegagalan lalu menambahkannya ke daftar regression test yang terus bertambah
  3. Mengutamakan solusi umum sambil memeriksa grammar dan cara implementasi acuan C++ menanganinya
  4. Setelah memperbaiki, mencetak ringkasan satu paragraf yang dapat dibaca manusia
  5. Menjalankan seluruh regression test untuk memastikan semua kasus lolos
  6. Menjalankan kembali proses yang sama secara otonom
• Karena parser baru jauh lebih cepat, ia dapat dijalankan bersama parser C++ lama dalam mode shadow di produksi dan melaporkan perbedaan hasil

Validasi Produksi dan Peralihan

• Dalam perbandingan awal menggunakan log kueri produksi, sekitar 50 ribu kueri diuji
• Dalam mode shadow, parsing dijalankan dengan cepat jutaan kali, dan tidak ada satu pun ketidaksesuaian dengan parser lama
• Awalnya mode shadow direncanakan dipertahankan selama beberapa hari, tetapi hasilnya cukup kuat sehingga trafik produksi dialihkan ke parser baru hanya dalam beberapa jam
• Setelah peralihan, shadow terbalik 0,1% tetap dipertahankan untuk membandingkan kembali dengan parser lama
• Parser baru menghasilkan bukan hanya AST, tetapi juga informasi posisi sumber yang sama dengan parser C++ ANTLR

70 Kali di Laptop, 454 Kali di Produksi

• Dalam benchmark laptop, performanya sekitar 70 kali lebih cepat daripada parser lama
• Pada kueri produksi, rata-rata menjadi 454 kali lebih cepat
  • Di produksi, SQL yang diproses umumnya lebih panjang dan tidak mengenai cache parser, sehingga perbedaan performanya lebih besar daripada di laptop
• Hasil akhirnya terdiri dari sekitar 16 ribu baris kode parser, sekitar 5 ribu baris alat, dan ribuan baris pengujian
• Untuk kueri realistis, hasilnya setara dengan parser lama, dan perbedaannya terbatas pada segelintir kueri yang disusun secara artifisial

Struktur Parser Akhir dan Cara Pengembangan yang Berubah

• Parser akhir terdiri dari struktur berikut
  • Sebagian besar diimplementasikan sebagai predictive recursive descent parser
  • Pemrosesan ekspresi menggunakan inti parser Pratt
  • Cursor dasar adalah LL(2), dan cakupannya diperluas hanya pada titik tertentu dengan eksplorasi lookahead terbatas yang tidak mengonsumsi input
  • Backtracking spekulatif lokal berbasis pilihan berurutan hanya diterapkan pada sedikit keputusan yang benar-benar diperlukan
• Seluruh parser ditulis dalam Rust oleh Claude Opus 4.7 pada Mei 2026, dan kode tidak ditulis langsung dengan tangan
• Konfigurasi PBT yang menghasilkan input dari grammar dan mengarahkan pembuatan dengan code coverage mendekati metode mutakhir dalam fuzzing parser, dan berbeda dari sekadar “vibe coding”
• Pekerjaan yang bahkan bagi developer dengan pengetahuan khusus parser bisa memakan waktu berbulan-bulan diselesaikan hanya dalam beberapa hari
• Ke depan, pola ketika parser generator seperti ANTLR menyediakan implementasi acuan, lalu LLM menulis parser implementasi langsung yang lebih cepat sambil menyamakan kesetaraan dengan PBT dan fuzzing, dapat menjadi umum