标签：#Database

DoltHub has recently released Dolt 2.0, a major update to the open source version-controlled SQL database. The latest major version adds automatic storage optimization, including garbage collection and compression, along with improved support for large and vector data types. By Renato Losio

This project was supposed to be a quick experiment. I had been reading about DNA storage and got carried away with the idea. DNA can pack a ridiculous amount of information into a tiny space. I started wondering if a database could behave a bit like a living system: the schema as its basic code, the queries as signals, and indexes changing as the workload changed. I spent two or three days building around that idea. Then I had to admit something fairly obvious. Most of what I was reading described DNA as an archival medium . It involves writing and reading physical DNA. That is nowhere near the speed or simplicity needed by a normal application database. Also, I am not a PostgreSQL expert. I was building an algorithmic-trading system, learning as I went, and trying to solve a problem I did not fully understand yet. When the sprint ended, I could not tell whether I had built something useful or just wrapped a lot of code around a clever-sounding metaphor. The literal DNA idea had to go. One smaller question survived: When somebody adds a new Postgres index, how do we know it is useful and not just valid-looking SQL? That question became IndexPilot. The problem I kept running into Adding an index looks simple: CREATE INDEX orders_customer_created_idx ON public . orders ( customer_id , created_at ); I could read that line. I could understand the intention. What I could not tell was whether the real database needed it. Maybe the query it is meant to help hardly ever runs. Maybe another index already covers the same columns. Maybe PostgreSQL would ignore it. Maybe it helps reads but adds more cost to every write. The SQL can look completely reasonable while the decision is still wrong. That felt like a useful place for a small tool. Not a tool that changes the database automatically. Just something that collects enough evidence to make the next review less guessy. What IndexPilot does IndexPilot reviews the exact CREATE INDEX statement in a migration. It can compare that

Most data engines can answer a query. I wanted one that could also explain, offline and byte for byte, why that answer belongs to a specific durable state. That question led me to build Hyphae , an open-source data engine in Rust with a deliberately small operational footprint: one native binary; one data directory; no required database, cache, cloud service, embedding provider, or LLM; deterministic KV and structured queries; portable result proofs that can be verified offline. If you read my earlier post about provenance over prediction , this is the next and deliberately narrower step. That work began as a cognitive substrate and clarified the provenance thesis. I have since rebuilt Hyphae as a standalone data engine. The research lineage remains, but the current product does not need an AI stack to be useful. Hyphae 0.1.0 is now available on GitHub , through crates.io, and as signed multiplatform archives in the first public release . The problem was not another query syntax The usual path for an application data feature grows surprisingly quickly. A local library becomes a database service. Search adds another service. Caching adds another. Semantic retrieval adds a model provider. Soon, a feature that should be optional controls whether the application can start at all. There is a second problem hiding underneath that operational stack: a successful response is usually just an assertion from the system that produced it. If I receive a filtered, sorted, limited result, how do I check that: the underlying durable state was not corrupted; the query was executed with the declared semantics; matching rows were not silently omitted; the returned result is tied to the state I actually intended to trust? Checksums help with corruption. Signatures can identify a producer. Neither one, by itself, proves that an arbitrary query result is complete and was reexecuted correctly. Hyphae is my attempt to make those concerns part of the engine instead of application glue. What

SQLite Internals: Win32 Malloc; PostgreSQL 19 LZ4 Compression, Spock 6 Beta Today's Highlights This week's database news highlights a critical discussion on SQLite's internal memory management for Windows, a major performance-boosting compression change planned for PostgreSQL 19, and the beta release of Spock 6 for multi-master PostgreSQL replication. Discussion on Dropping SQLITE_WIN32_MALLOC Support (SQLite Forum) Source: https://sqlite.org/forum/info/e280641d16b70a0980c5409280cfda598b2141a41cbd63be86e943ea334f346f This forum discussion centers on the potential removal of SQLITE_WIN32_MALLOC support in future SQLite versions. SQLITE_WIN32_MALLOC is a compile-time option that allows SQLite to use Windows-specific memory allocation functions (like HeapAlloc , VirtualAlloc ) rather than its default internal memory allocator or the standard C malloc / free . The primary motivation for considering its removal appears to be reducing code complexity and maintenance burden, as this specific memory allocation strategy is less commonly used by the broader SQLite developer community. Developers who embed SQLite into Windows applications and have configured custom memory management (e.g., for specific performance tuning, memory tracking, or integration with application-level memory pools) often rely on this option. Its deprecation would necessitate a review of their build processes and potentially a migration to a different memory allocation strategy, such as SQLite's default options or their own custom sqlite3_config() hooks. The conversation delves into the trade-offs between backward compatibility, library size, and ongoing maintainability, highlighting the intricacies of supporting a highly configurable, embedded database system across diverse environments. Comment: This discussion is crucial for anyone embedding SQLite on Windows with specific memory management requirements. It's a clear signal to start evaluating alternative memory allocation strategies for future-proof

I've been using TablePlus for years. It's good — but the connection limits on older licences drove me mad, and most alternatives are either Electron apps or haven't been updated since 2019. So I built my own. What is Stratum? Stratum is a native macOS database GUI — written in Swift, not wrapped in Electron. It connects to MySQL, MariaDB, PostgreSQL, and SQLite. What made me actually build it Three things: 1. Connection limits. TablePlus caps connections on older licences. Stratum has none. 2. Electron alternatives. Beekeeper Studio is good but it's an Electron app. On a Mac, that matters. 3. The MySQL setup friction. Most tools require you to install extra dependencies. Stratum connects natively — no brew install, no extra setup. What it does Table browser with inline editing — add, edit, delete rows without SQL Server-side pagination — stays fast on tables with 100k+ rows Query editor with schema-aware autocomplete Visual schema designer — create tables, add columns without writing DDL Full SQL export — DROP + CREATE + batched INSERTs iCloud sync for connections and snippets Laravel Valet auto-detection Import connections from TablePlus in one click SSH tunnelling The tech Built with SwiftUI and Swift 6. The PostgreSQL driver uses PostgresNIO. The MySQL driver implements the MySQL wire protocol directly over Network.framework — no Homebrew dependency, works inside the App Sandbox. Where it is now Currently in free beta. One-time purchase planned for the Mac App Store — no subscription. → stratum.mwn-digital.uk Happy to answer questions about how it's built.

Your Test Data May Be More Dangerous Than Your Production Database Most organizations protect production databases carefully. Access is restricted, activity is logged, and security teams monitor unusual behavior. Then a copy of the same data is exported into a test environment, sent to an analytics team, or shared with an outside service provider. At that moment, the protection model often becomes much weaker. The copied database may contain customer names, phone numbers, account details, identification numbers, medical information, transaction histories, or internal employee records. Developers may need realistic data structures, but they rarely need to see the real identities behind them. Operations teams may need to investigate a production issue, but they do not always require full access to sensitive fields. This is where data masking becomes a practical security control. It allows useful data to remain available while reducing the exposure of the people and organizations represented inside it. The Real Risk Begins When Data Starts Moving Sensitive data rarely stays in one place. It flows from production into testing, development, quality assurance, reporting, analytics, migration projects, outsourced support, and third party platforms. Every new copy expands the attack surface. A production database may have strong access controls, but a test database may be managed by a broader team. A temporary migration environment may remain online longer than planned. A dataset shared for analytics may contain fields that were not necessary for the project. The security problem is therefore larger than database access. It is about controlling what information remains visible as data moves through the organization. Data masking changes sensitive values while preserving their structure and usefulness. A masked phone number can still look like a phone number. A substituted customer name can still support application testing. A shuffled account value can preserve distribution

Your data warehouse has a table called orders . It has columns like amount , status , created_at , and customer_id . Now three people ask "What was Q1 revenue?" The analyst writes SELECT SUM(amount) FROM orders WHERE created_at BETWEEN '2026-01-01' AND '2026-03-31' . The data engineer adds WHERE status = 'completed' . Finance excludes refunds and trial conversions. Three queries, three numbers, one question. Nobody is wrong. They just defined "revenue" differently. Multiply this by every metric in your organization, every team that queries the warehouse, and every tool that displays a number. That's the problem. A semantic layer solves it by defining each metric once, in one place, and serving that definition to every consumer. What is a semantic layer? A semantic layer is a metadata layer between your data warehouse and every tool that queries it. It defines business metrics, maps them to SQL, and exposes them through APIs. Instead of every consumer writing its own query, they all reference the same definition. When someone asks for "revenue," the semantic layer knows that means: SUM ( CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END ) That definition lives in one place. Dashboards, APIs, AI agents, and ad-hoc queries all use it. Change the definition once and every consumer gets the updated calculation. No Slack thread asking "which number is right." No detective work tracing a wrong number back to a stale query in a notebook somewhere. The core components of a semantic layer: Metrics (measures). The numbers you aggregate: revenue, order count, average deal size. Each metric has a fixed SQL definition. Dimensions. The columns you filter and group by: date, status, category, region. Dimensions define the axes of analysis. Relationships (joins). How tables connect: orders belong to customers, products belong to categories. Defined once, reused by every query. Access rules. Who can see what. Row-level security, tenant isolation, role-based ac

"We need real-time analytics" is one of the most common requests in data engineering. It's also one of the most misunderstood. When the VP of Sales says "real-time," they usually mean "faster than the dashboard that refreshes overnight." When the CTO says it, they might mean sub-second event streaming. The gap between those two definitions is a 6-month infrastructure project. Most teams don't need true real-time. They need fast enough. And "fast enough" is achievable with pre-aggregation caching at a fraction of the complexity and cost of a streaming architecture. What is real-time analytics? Real-time analytics means querying data with minimal latency between when an event happens and when it's visible in your analytics. The spectrum: Freshness Latency Architecture Use case True real-time < 1 second Event streaming (Kafka, Flink) Fraud detection, stock trading, live monitoring Near real-time 1-60 seconds Micro-batch or streaming Operational dashboards, alerting Frequent refresh 1-60 minutes Scheduled refresh + caching KPI dashboards, AI agent queries Batch Hours to daily Scheduled ETL Board reports, monthly summaries Most analytics use cases fall in the "frequent refresh" category. Revenue by region doesn't need sub-second freshness. Active users in the last hour doesn't need event streaming. A pre-aggregation cache that refreshes every 15 minutes covers 90% of what teams call "real-time." When you actually need real-time True real-time analytics (sub-second latency from event to query result) is worth the infrastructure investment when: Fraud detection. Every second of delay is potential fraud that slips through. Live monitoring. Server health, API error rates, active user counts for live products. Trading and pricing. Financial instruments where stale data means wrong prices. Live events. Streaming metrics during a product launch, marketing campaign, or live broadcast. If you're in one of these categories, you need an event streaming architecture: Kafka, Flink, M

Most teams connecting AI agents to their data warehouse start with text-to-SQL. The agent generates SQL from natural language, runs it against the warehouse, and returns results. It works until it doesn't: hallucinated JOINs, inconsistent aggregations, no access control, no audit trail. There's a better approach. Define your business metrics in a semantic layer, expose them via MCP (Model Context Protocol), and let any AI agent query governed definitions instead of raw tables. Then add one tool so the agent can chart the result in Claude or ChatGPT. This tutorial shows how to set it up in under 30 minutes. Why does text-to-SQL break in production? The agent sees column names but not business logic. It doesn't know that your company excludes refunds from revenue. It doesn't know that status = 'completed' means something different in orders than in subscriptions . It doesn't know that marketing and finance defined "active user" differently three years ago and never reconciled. So the agent writes plausible SQL and returns plausible numbers. Ask the same question twice with different phrasing and you get different answers. Ask two different agents and you get two different numbers. Neither matches the number your finance team reports. Beyond consistency, there's no row-level security. No multi-tenancy. No audit trail showing which agent queried what, when, and for whom. In production, with real customers, that's a non-starter. Text-to-SQL gives you speed. It doesn't give you trust. What is the semantic layer approach? Instead of letting agents write arbitrary SQL, define your metrics once in YAML: cubes, measures, dimensions, access rules. Then expose those definitions via MCP so agents query governed metrics, not raw tables. The difference: every agent gets the same answer because the metric definition is fixed. total_revenue isn't a column the agent interprets. It's a pre-defined calculation with agreed-upon filters and aggregations. When your finance team updates th

I made ClickHouse and Postgres Fight to Find Out 🥊 One Mac Mini. Two databases. 100 million rows of...

Database branching is one of the best ideas serverless Postgres brought to the mainstream. Fork the database at a point in time, get an isolated copy with all the data, run something risky against it, throw it away. It made preview databases and safe migrations feel routine. But a real application is not just a database. It is a database, plus the files it stores in object storage, plus the backend code that serves it, plus, increasingly, the model and gateway config it calls for AI. When you branch only the database, those other three stay shared. Your "branch" points at the same S3 bucket, the same deployed backend, and the same AI configuration as everything else. So it is half a copy, and the half it leaves out is where a lot of the interesting bugs and the scary migrations live. Neon's platform preview changes what a branch contains. A branch now forks the database and its data, the object storage and its files, the functions that run your backend, and the AI gateway config, all at the same point in time, all isolated. A branch stops being a database copy and becomes a whole environment. To make sure that is a real claim and not a diagram, I took a full-stack project, branched it, and checked every layer. Here is what happened. TL;DR Elsewhere, "branch" means the database only. Object storage, backend deploys, and AI config stay shared, so you bolt on scripts to fake per-branch versions of them. A Neon branch forks all four together: Postgres + data, object storage + files, functions (each branch gets its own URL), and the AI gateway. I proved it: branched a project with a DB, a bucket of files, a function, and the gateway. The branch came up with a copy of the rows, a copy of the files on its own storage endpoint, its own function URL, and the gateway. A write to the branch left main untouched, and deleting the branch removed all of it. That makes a branch a real environment: true preview stacks, whole-state bug reproduction, and disposable sandboxes for agent

Twelve pricing tabs open. Neon, Hetzner, Supabase, Prisma, Scaleway, OVH. My database is half a gigabyte. I was comparing ten-terabyte price curves. At some point this week I typed the words "I am super lost here" about my own infrastructure. I advise companies on this exact class of decision. That sentence still came out of my hands. If you have ever spent an evening deep in provider pricing pages for a workload that fits on a USB stick from 2009, this one is for you. All numbers below come from the live pricing pages as of July 2026. Rates move, so verify before you commit. Three fears, all pointed at the wrong layers I went in worried about getting attacked, running out of space, and being locked in. All three dissolved under ten minutes of honest reading. DDoS lands on the website edge, not the database. My site already sits behind Cloudflare and Vercel, and a database is never publicly exposed. Only the app talks to it. Whichever provider I picked, that attack surface stayed identical. Here is the shape of the stack, and where each fear lives. MANAGED (what I run today) visitors ──> Cloudflare edge ──> Vercel app ──> managed Postgres [DDoS absorbed] [stateless] [never public, app-only access, provider patches, provider backups, provider on-call] SELF-HOSTED (the alternative I priced) visitors ──> Cloudflare edge ──> Vercel app ──> Hetzner CAX11 [DDoS absorbed] [stateless] [Postgres :5432 firewalled to app, SSH hardened, fail2ban + auto- patching = MINE] │ pg_dump every 6h ▼ encrypted ────> Cloudflare R2 [off-site copies] Same edge, same app, same attack surface. Everything in the right-hand box is what changes owners. Storage was a rounding error. My data is 0.5 GB. Even the cheapest self-hosted box includes 40 GB, eighty times headroom before the first extra cent. Lock-in was a phantom too. Managed Postgres is still stock Postgres. Exiting means a dump, a restore, and one connection string change in the deployment environment. Minutes of cutover, no rewrite an

SQLite Internals: lcd-ex vs hctree; PostgreSQL 19 SQL/PGQ Rewrites & pg_timetable Migration Today's Highlights This week's highlights feature a deep dive into SQLite's internal data structures, offering insights for advanced optimization. Also, PostgreSQL users gain practical guidance on migrating to pg_timetable for robust job scheduling and understanding how SQL/PGQ translates to efficient joins in PostgreSQL 19. Replacing pgAgent with pg_timetable: Installing as a Linux Service (Planet PostgreSQL) Source: https://postgr.es/p/9pE Regina Obe presents a crucial guide for PostgreSQL administrators looking to modernize their task automation by replacing pgAgent with pg_timetable . This second part of the series focuses specifically on the practical steps of installing and configuring pg_timetable as a systemd service on Linux, ensuring it runs reliably in a production environment. The article details the process from downloading binaries and creating dedicated user accounts to setting up service files and enabling autostart, providing a comprehensive walkthrough for seamless integration. pg_timetable offers significant advantages over pgAgent , including advanced scheduling capabilities, event-driven task execution, parallel job processing, and improved logging. This migration strategy is vital for enhancing the robustness and efficiency of database maintenance, data synchronization, and complex ETL pipelines within the PostgreSQL ecosystem. By following this guide, developers and DBAs can transition to a more powerful and flexible job scheduler, leading to greater control and reliability over their automated PostgreSQL operations. Comment: Migrating to pg_timetable from pgAgent is a significant step forward for job scheduling in PostgreSQL. This guide provides the hands-on steps needed to get it running as a service, which is essential for any production deployment. SQLite Forum Discusses lcd-ex vs hctree (SQLite Forum) Source: https://sqlite.org/forum/info/3494bff42

RocheDB v0.5.0 has been released. Release: github.com/puffball1567/rochedb/releases/tag/v0.5.0 RocheDB is an open-source NoSQL document and vector store written in Nim. The project is built around one idea: Data locality should be part of the database model, not only an accidental result of indexes, caches, or application code. A lot of database performance discussions start with indexes, query syntax, or caches. Those are important. But layout often decides whether a system is working with the hardware or asking it to fight back. RocheDB v0.5.0 is a step toward making locality explicit at three levels: logical placement with rings; related-data retrieval with stellar locality; physical layout visibility with WAL locality reporting. Ring locality RocheDB uses a ring as a semantic and structural placement unit. An application, import rule, or operator chooses a ring when writing data: users/123/profile users/123/orders shops/1123/orders docs/japan/support tenant/acme/orders/2026 That ring is not only a directory-like label. It is a coordinate in the retrieval space. When a request already knows its natural locality, RocheDB can open that local region first instead of scanning unrelated records and filtering later. roche put --ring = docs/japan --payload = '{"title":"Refund guide","status":"draft"}' --codec = json roche get --ring = docs/japan --filter = '{"status":"draft"}' --selection = '{ title }' The important part is not the string syntax. The important part is that placement and retrieval scope are connected. Short version: a ring is both where data is placed and where retrieval can start. Not only point reads Point reads are important, but many real applications need related data. For example, a user page may need profile data, orders, billing information, and support metadata. In a relational database, that often becomes joins. In a document database, it often becomes manual denormalization or multiple application-side reads. RocheDB v0.5.0 adds a locality mec

One of the most common questions I hear is: "My API is slow. Where do I start?" The first instinct is usually: Upgrade the server Increase CPU Add more RAM But in many cases, the database query is the real bottleneck . Whenever I investigate a slow Laravel application, I follow the same checklist. It helps me identify performance issues before making unnecessary infrastructure changes. Let's go through it. 1️⃣ Find the Slow Queries First Don't start optimizing random queries. Start with the queries that are executed the most or take the most time. Useful tools: Laravel Telescope Laravel Debugbar (development) MySQL Slow Query Log Application Performance Monitoring (APM) You can't optimize what you haven't measured. 2️⃣ Stop Using SELECT * One of the easiest improvements. ❌ Instead of: SELECT * FROM users WHERE id = 10 ; Use: SELECT id , name , email FROM users WHERE id = 10 ; Why? Less data transferred Lower memory usage Faster response Easier for MySQL to use covering indexes Only fetch the columns your application actually needs. 3️⃣ Always Check the Execution Plan Before changing anything, run: EXPLAIN SELECT id , name FROM users WHERE email = 'john@example.com' ; Things I usually look for: Is MySQL scanning the whole table? Is an index being used? How many rows are examined? Is there a temporary table? Is filesort being used? EXPLAIN often tells you exactly why a query is slow. 4️⃣ Verify Your Indexes Indexes are one of the biggest performance improvements you can make—but only when they match your queries. Example: SELECT * FROM orders WHERE customer_id = 100 ; Create an index: CREATE INDEX idx_customer_id ON orders ( customer_id ); Now MySQL can jump directly to the matching rows instead of scanning the entire table. 5️⃣ Look for Composite Index Opportunities Suppose your query is: SELECT id , total FROM orders WHERE customer_id = 10 AND status = 'paid' ; Instead of two separate indexes: customer_id status A composite index is often better: CREATE INDEX idx_cu

7 MongoDB Query Mistakes That Return the Wrong Results VisuaLeaf VisuaLeaf VisuaLeaf Follow Jul 14 7 MongoDB Query Mistakes That Return the Wrong Results # mongodb # coding # software # database 3 reactions Add Comment 5 min read

MongoDB queries look simple. You type a field, give it a value, hit run, and you get your data back. But just because a query runs without throwing an error doesn't mean it worked right. Sometimes you get a blank screen. Sometimes you get way too many records. Other times, the data looks fine at first glance, but it doesn't actually match what you asked for. Most of these slip-ups happen for one basic reason: the query structure doesn't match the way the data actually sits in the database. To show you what we mean, we’ll use a clinic database with a collection called visits . Here is what a typical document looks like: JSON { "_id": "6871b6f9c3f1d1a4c2a10001", "status": "completed", "visitDate": "2026-07-01T09:30:00.000Z", "patient": { "name": "Anna Keller", "age": 34 }, "doctor": { "name": "Dr. James Carter", "specialty": "Cardiology" }, "symptoms": ["cough", "fever"], "prescriptions": [ { "name": "Ibuprofen", "active": false }, { "name": "Paracetamol", "active": true } ], "invoice": { "paid": true, "method": "card", "total": 250 } } You can run these examples right in the VisuaLeaf MongoDB Shell . Using visual tools makes a big difference because you can see exactly what MongoDB is returning in real time. 1. Forgetting the Curly Braces This is just a quick typo, but it breaks things right away. The Mistake: db . visits . find ( status : " completed " ) The Correct Query The find() tool always expects an object. Even if you are only looking for one specific thing, you still need to wrap that condition in curly braces {} . 2. Treating $or Like a Regular Object This one trips a lot of people up because the broken version looks like it should work. The Mistake: db.visits.find({ $or: { status: "completed", "invoice.paid": false } }) What is wrong: $or expects an array of conditions, but this query gives it one object. The error will usually be something like: MongoServerError: $or must be an array The Correct Query The first query is wrong because $or needs an array, n

DuckDB Iceberg MERGE, PostgreSQL GUCs, SQLite Optimization Checklist Today's Highlights This week's highlights include powerful new Iceberg data manipulation features in DuckDB v1.5.3 and a deep dive into an obscure PostgreSQL GUC. Plus, the SQLite community discusses a practical optimization checklist for embedded databases. New DuckDB-Iceberg Features in v1.5.3 (DuckDB Blog) Source: https://duckdb.org/2026/05/29/new-iceberg-features.html The latest DuckDB v1.5.3 release significantly enhances its integration with Apache Iceberg, introducing a suite of powerful new features for data engineers and analysts. Key among these are the support for MERGE INTO and ALTER TABLE statements, allowing for more robust data manipulation directly within DuckDB for Iceberg tables. This update enables complex operations like upserting data based on conditions, schema evolution (e.g., adding/dropping columns), and modifying table properties, all achievable through a familiar SQL environment. This capability is crucial for maintaining data integrity and adapting schemas without complex external tooling. Furthermore, DuckDB-Iceberg now supports partition transforms, making it easier to manage and query partitioned Iceberg datasets efficiently by defining how data is distributed across files. The release also brings support for Iceberg V3, ensuring compatibility with the latest features of the Iceberg format, including new manifest list and manifest file layouts which offer performance improvements. These additions position DuckDB as an even stronger tool for building performant data pipelines and performing complex analytics directly on large-scale Iceberg data lakes, fully leveraging DuckDB's in-process analytical capabilities and the flexibility of the Iceberg table format. Comment: This update is a game-changer for working with Iceberg tables directly in DuckDB. MERGE INTO support means simplified ETL for incremental loads, and V3 compatibility ensures we're ready for future Iceberg

The ScyllaDB PHP driver is not a C++ extension anymore. As of 1.4.0 it's pure C23, the ZendCPP template layer we leaned on for the object embed and allocate pattern is deleted, and the build no longer needs a C++ compiler at all. Every hand-written .cpp file is a .c file now (71 of them), the descriptor generator emits .c , and CMake builds with c_std_23 and nothing else. That's the biggest change to how this extension is built since we forked it for PHP 8.0. This is also the release where a plan I opened back in 2023 finally landed. PR #50 laid it out: rewrite the src/Cluster directory to be more maintainable, use Zend Fast Argument Parsing, remove some memory allocations, and add .stub.php files that generate the C headers so nobody has to hand-maintain Zend arginfo by hand. 1.4.0 is that plan finished, and a lot more that grew out of it. The things you'll actually feel: persistent session connect() doesn't allocate a 200-character key string on every call anymore, and the minimum PHP is now 8.3 (8.2 is gone). Nothing in your application code changes, this is almost all under the surface. The .stub.php Build The idea from PR #50 was small. Instead of writing ZEND_BEGIN_ARG_INFO_EX blocks by hand and keeping them in sync with the actual method bodies, write the signature once in a .stub.php file and generate the C arginfo from it. In v1.4.0 that's the whole build. There are 75 .stub.php files now, and each one is just the PHP signature of the class: // src/Keyspace.stub.php interface Keyspace { public function name (): string ; public function replicationClassName (): string ; /** @return array<string, mixed> */ public function replicationOptions (): array ; public function hasDurableWrites (): bool ; /** @return Table|false */ public function table ( string $name ): Table | false ; public function aggregate ( string $name , mixed ... $types ): Aggregate | false ; } At build time CMake runs gen_stub.php (vendored from PHP 8.5's build/gen_stub.php , with two small p

How I Built CodeGraph: A Living Knowledge Graph That Tells You What Breaks Before You Break It Built for HACKHAZARDS '26 — powered by Neo4j AuraDB, tree-sitter, Groq LLaMA, and Next.js The Problem That Frustrated Me Every developer knows this feeling. You join a new codebase. There are 50,000 lines of code. Your manager says "just fix this small bug in the authentication module." You make the change. You push. And suddenly three completely unrelated features are broken — a payment flow, a notification system, and a dashboard widget you've never even looked at. You spend the next four hours tracing function calls manually, reading code you've never seen, trying to understand why changing one function in auth.py broke something in notifications.py on the other side of the codebase. This is not a rare experience. According to JetBrains' developer survey, engineers spend 58% of their time reading and understanding code — not writing it. One wrong change in a large codebase can cost hours of debugging, failed deployments, and frustrated users. I built CodeGraph to solve this. Not with another AI chatbot that guesses at your code. With a real, queryable knowledge graph that actually understands how your codebase is connected. What CodeGraph Does CodeGraph takes any public GitHub repository URL and within seconds: Parses every function in the codebase using tree-sitter Maps every call relationship between functions as a directed graph Stores everything in Neo4j AuraDB as a live knowledge graph Lets you ask questions in plain English — answered by AI grounded in real graph data The result: paste a GitHub URL, see your entire codebase as an interactive graph, click any function, and instantly know what breaks if you change it. The Tech Stack Here's what I used and why each choice mattered: Backend: Python + FastAPI (REST API server) Neo4j AuraDB (graph database — the core of everything) tree-sitter (AST parser for Python, JS, TS, TSX) Groq API with LLaMA 3.3 70B (free-tier L