标签：#base

Disclaimer: This is a side project, not a production story. The slow-query problem is real, but the database is synthetic data I generated to make it show up on demand. I have no connection to PgCache. Everything here is in a repo you can clone and run. I tested version 0.6.2. A handful of dashboard queries on one of my projects were fine for a year and then weren't: count users by tier, revenue grouped by country, best-selling products per category. Nothing exotic, just aggregates and joins over tables that had gotten big. The usual fixes didn't sit right with me. A materialized view means picking a refresh interval and serving slightly stale numbers in between. Redis in front of Postgres means writing and maintaining code that knows which cache entries to throw away on every write. A read replica just runs the same slow query on another machine. PgCache offers a different trade. It's a proxy that talks the Postgres wire protocol, so your app connects to it as if it were the database. It caches reads. And instead of expiring entries on a timer, it follows Postgres's replication stream and refreshes a cached result when the rows behind it change. That stream is the same feed Postgres uses to copy data to a standby server , a running log of every insert, update, and delete. The "no timers, no manual invalidation" part is the interesting claim. Here's how it held up. A database big enough to be slow First I needed a database where "slow" was real and not a rounding error. I wrote a seed script for a small e-commerce schema and filled it to about 16 million rows: Table Rows Notes users 1,000,000 10 countries; tiers 50% free / 33% pro / 17% enterprise products 2,000 10 categories orders 5,000,000 four statuses, random totals, spread over two years order_items 10,000,000 about two per order I added indexes on every foreign key and on every column the test queries filter or group by. That was on purpose. I wanted to compare PgCache against a Postgres that had been tuned p

What building a warehouse management system taught me about the data operational software leaves behind — and the engineering it takes to make that data trustworthy. The second that outlives itself A picker holds a handheld scanner, points it at a carton, and pulls the trigger. There's a beep. They type 10, confirm, and move to the next location. The whole thing takes about a second. For a long time I thought of my job as making that second work. I built the screen, the endpoint behind it, the repository behind that. My definition of done was that the user completed the workflow, the API returned success, and the right rows landed in the database. What changed my thinking was noticing what was still there afterwards. The screen closes, the session ends, the app ships a new version, the picker changes jobs, the device is replaced. The row stays — and the row isn't a record of a UI interaction. It's a durable claim about the physical world: at this time, this person, on this device, ten units of this product moved. The application is the instrument. The data is the measurement. A measurement is only ever worth what the instrument's precision allows. This article is about the gap between those two definitions of done, and the specific decisions — retry semantics, timestamps, identity, status codes, conflict resolution — that determine which side of it you land on. Almost all of them get made by application developers, inside feature work, long before anyone tries to analyze anything. What warehouse owners actually do with this data now Worth being concrete about the stakes first, because "data quality matters" is the kind of statement everyone agrees with and nobody acts on. What's changed isn't that owners suddenly became analytical. It's that operational systems started producing enough granular, attributed, time-stamped movement data that previously unanswerable questions became answerable. Inventory accuracy is a working-capital decision. Stock you can't trust is s

When you're building a multi-tenant app, there's one bug category that's worse than any other: a user seeing someone else's data. Not a crash, not a broken button — a genuine privacy failure. I recently built a Next.js + Supabase + Stripe starter kit, and before I'd call the database layer "done," I wanted to actually prove the security held, not just assume it did because the code looked right. The setup Supabase's Row Level Security (RLS) lets you write policies directly in Postgres that filter rows based on who's asking — the database itself becomes the security boundary, not just your application code. That's powerful, but it also means a single wrong policy (or a missing one) silently exposes everything. Here's the policy pattern I used for an owner-scoped table: create policy "projects: owner reads" on public . projects for select to authenticated using (( select auth . uid ()) = owner_id ); Simple enough. But "simple enough" is exactly the kind of thing worth verifying rather than trusting. The actual test Rather than just trusting the policy, I ran an impersonation test directly in the SQL editor: begin ; set local role authenticated ; set local request . jwt . claims = '{"sub":"<a-real-user-id>"}' ; select id , name from public . projects ; rollback ; This temporarily pretends to be a specific user (inside a transaction that touches nothing) and asks: what can this user actually see? Run it with the real owner's ID — you get their rows. Run it with a fake or different user's ID — you should get zero rows back, not an error. That's the key detail: RLS filters rows out silently rather than throwing a permission error, so "nothing happened" is actually the success signal, not a bug. I did the same check for writes — attempting to delete another user's row from a different account's session, confirming it returns 0 rows affected rather than either succeeding or throwing. Why this matters more than it seems It's easy to write an RLS policy that looks right and s

Adding an index stops working eventually. Here's what we did when a nationwide logistics platform's core table crossed a billion rows — and the parts nobody warns you about. There's a specific moment in a backend engineer's life when the usual advice stops working. A query gets slow. You check the execution plan, you add an index, it gets fast again. This works for years. It works so reliably that it starts to feel like a law of nature. Then one day you add the index and nothing happens. Or worse — the index takes six hours to build, locks the table while it does, and the query is still slow at the end of it. That's roughly where we were on a nationwide logistics platform processing tens of thousands of orders a day. The tracking events table — one row per scan, per parcel, per status change — had crossed a billion rows. Every parcel generated a dozen or more events on its journey. The table only ever grew. This is what we did about it, and more usefully, what nobody told us beforehand. First: are you sure you need this? Partitioning is not a performance trick you reach for when a query feels sluggish. It carries real operational cost, and most tables that people want to partition should just be indexed properly. Some honest signals that you're actually at the boundary: Your indexes no longer fit comfortably in memory, so index reads hit disk Index maintenance — REINDEX, VACUUM, ANALYZE — takes so long you can't schedule it Deleting old data is impossible in practice, because a DELETE of a hundred million rows will destroy your write throughput for hours Your queries almost always filter on a single obvious dimension, usually time That last one matters more than the rest. Partitioning only helps if your access pattern lines up with how you split the data. If your queries hit every partition anyway, you have added complexity and gained nothing. For us the alignment was clean: nearly every query on the events table was scoped to a date range. Operations dashboards loo

Last week I wrote about the French voiceover API that only accepts payment from robots . Today: the part people actually asked me about — how do you verify a $0.05 payment on-chain with zero payment processor, zero SDK, and zero KYC? The answer: one Python function, ~40 lines, stdlib only. Here's the real production code. The setup My endpoint sells French neural TTS voiceovers for $0.03–0.05 USDC. At that price, Stripe is a non-starter (their floor is ~$0.50 per charge) and any processor's KYC kills the "robots welcome" model. So payments go through the x402 pattern: client pays USDC on Base, sends me the transaction hash, I verify it myself against a public RPC before delivering. The verification function import json , os , urllib . request WALLET_BASE = " 0x3f97...D074 " # where I receive USDC_BASE = " 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 " # USDC on Base BASE_RPC = " https://mainnet.base.org " TRANSFER_TOPIC = " 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef " def rpc ( method , params ): req = urllib . request . Request ( BASE_RPC , data = json . dumps ({ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : method , " params " : params }). encode (), headers = { " Content-Type " : " application/json " }) with urllib . request . urlopen ( req , timeout = 30 ) as r : return json . load ( r ). get ( " result " ) def verify_payment ( tx_hash , min_usdc ): # 1. format sanity if not tx_hash . startswith ( " 0x " ) or len ( tx_hash ) != 66 : return False , " bad hash format " # 2. anti-replay: one hash = one delivery if tx_hash . lower () in load_used_txs (): return False , " tx already used (replay) " # 3. fetch the receipt receipt = rpc ( " eth_getTransactionReceipt " , [ tx_hash ]) if not receipt : return False , " tx not found on Base " if receipt . get ( " status " ) != " 0x1 " : return False , " tx failed on-chain " # 4. scan logs for a USDC Transfer TO my wallet want_to = WALLET_BASE . lower (). replace ( " 0x " , "" ) for log in receipt

Every value in my little embedded key-value store gets encrypted, then its ciphertext gets encoded as a string of A/C/G/T characters before it ever touches the filesystem. Open the file in a text editor and you'll see actual DNA-looking text - not because it's a gimmick, but because that's genuinely the storage format. This is mdc-lite , a ~348KB embeddable encrypted key-value store I built in Rust for places a server can't reach - a watch face, a phone app, a background service. It's part of a larger repo, ModelDB , that also includes MDC, a Python conversational data engine (query AI models, databases, images, and documents in plain English, no SQL) with its own DNA-inspired archival storage tier. The actual storage format Every put() call does this, in order: Pack [key_len][key_bytes][value_bytes] into one plaintext buffer. Encrypt the whole thing with XChaCha20-Poly1305 (a 256-bit key you supply - the crate never generates or stores key material itself; real key custody belongs to the platform's secure hardware, iOS Secure Enclave or Android Keystore). DNA-encode the resulting [nonce][ciphertext][tag] blob: 2 bits per base, 00→A 01→C 10→G 11→T . Every byte maps to exactly 4 bases, so there's no padding ambiguity on decode. Write the ACGT text to disk, atomically (temp file + rename). Filenames are keyed BLAKE3 hashes of the logical key, not the key name itself, so a directory listing alone leaks nothing - no key names, no values, no way to tell how many distinct keys exist versus how many files are on disk. rust pub fn put(&self, key: &str, value: &[u8]) -> Result<(), LiteStoreError> { let mut plaintext = Vec::new(); plaintext.extend_from_slice(&(key.len() as u16).to_le_bytes()); plaintext.extend_from_slice(key.as_bytes()); plaintext.extend_from_slice(value); let nonce = XChaCha20Poly1305::generate_nonce(&mut OsRng); let ciphertext = self.cipher().encrypt(&nonce, plaintext.as_ref())?; let mut record = nonce.to_vec(); record.extend_from_slice(&ciphertext); let ac

The second you hit Enter Friday night. You ask Cursor for a query: join orders to users, sort by last login. Three seconds later, an answer arrives with DBA-level confidence: SELECT o . id , o . amount , u . last_login_at FROM biz_order o JOIN sys_user u ON u . id = o . user_id ORDER BY u . last_login_at DESC ; Paste it into your client. Enter: ERROR: column "last_login_at" does not exist LINE 2: SELECT o.id, o.amount, u.last_login_at There is no last_login_at column. There never was. The model did not know — it just decided the column "should" exist. This failure has a name: invented column This is not "AI is not smart enough yet." It has a name — invented column : the model fabricates a plausible column name with no factual source, then writes it into a JOIN with unshakable tone. Invented columns are dangerous because they do not look like errors . last_login_at appears on 90% of user tables. Syntax is correct. Naming is conventional. Indentation is perfect. Mixed into ten correct JOINs, you will not catch it line by line. You find out in code review — or worse, in production logs. Three things you already tried A better prompt. "Do not invent column names; only use the schema I provide" — added to the system prompt. Works day one. By day three, long context and the model forgets. A prompt is a wish, not a constraint. @schema.sql . Export DDL and drop it into context. The most honest approach today — but two holes: it goes stale (last week's export does not know this week's column), and nobody maintains it (not in any approval flow; anyone can edit it; drift from the real database goes unnoticed). Live catalog MCP. Let the Agent query information_schema directly. Directionally correct — give the model a fact source instead of guesses. Tools like postgres-mcp and cloud vendor MCPs do solve half of "stop hallucinating column names." Worth acknowledging. Live catalog only gets you halfway Wire production into the IDE and you hit four walls: Permission-filtered inform

By Michael Nocito , data analyst · Published August 8, 2026 By the end of this page you will be running SQL directly against a CSV file on your machine, with no import step, no CREATE TABLE , and no schema written by hand. DuckDB reads the file where it lies, works out the column types itself, and gives you a normal SQL result. It takes one command to install and about a minute to prove. Here is what to actually do today. Run python -m pip install duckdb , then write a query with your CSV's filename in quotes where the table name would normally go. That is the entire idea, and everything else on this page is a consequence of it. The short version: a file is a table. It suits large files and folders of files, it does not replace SQLite for a shared database you keep, and section 6 says which to use when. The missing import step is the one idea worth the page, so it gets the picture. The original carries a diagram here. In words: Two horizontal sequences. The upper sequence runs through four stages joined by arrows: a file icon, then a box representing a schema being written, then a database cylinder, then a result grid. The lower sequence has only two stages joined by a single long arrow: the same file icon on the left and the same result grid on the right, with the middle two stages absent and the empty space where they used to be left visibly blank. Every output on this page is real. Run on 8 August 2026 with DuckDB 1.5.5 on Windows, against a 412-row CSV exported from the Chinook sample database. The numbers match the ones in the sample-database guide and the Python guide on purpose, because it is the same data through three different tools. 1. Install it Before the explanation: every database you have met so far needed you to create a table before you could put anything in it. What would have to be true for that step to be unnecessary? python -m pip install duckdb That is the whole installation. No server, no service running in the background, no configuration fi

Many engineers believe Common Table Expressions (CTEs) are always faster than subqueries. In modern SQL Server (and PostgreSQL), that is a myth . Here is what actually happens under the hood: 1. Inlining & The Query Optimizer By default, the SQL optimizer treats standard CTEs and derived tables (subqueries) almost identically: The engine expands both into the same relational tree. They generate the exact same execution plan and I/O cost . -- Pattern A: Derived Table (Subquery) SELECT DeptID , EmpName , Salary FROM ( SELECT DeptID , EmpName , Salary , DENSE_RANK () OVER ( PARTITION BY DeptID ORDER BY Salary DESC ) AS rnk FROM Employees ) RankedData WHERE rnk <= 2 ; -- Pattern B: Common Table Expression (CTE) WITH RankedData AS ( SELECT DeptID , EmpName , Salary , DENSE_RANK () OVER ( PARTITION BY DeptID ORDER BY Salary DESC ) AS rnk FROM Employees ) SELECT DeptID , EmpName , Salary FROM RankedData WHERE rnk <= 2 ; 2. When CTEs Truly Win: Readability & Pipeline Stacking: You can chain 5 CTEs sequentially without deeply nested pyramid brackets. In-Place Deduplication: In SQL Server, you can run DELETE directly on a CTE, and it deletes duplicate rows straight from the real underlying table! WITH DuplicateCleaner AS ( SELECT CustomerID , Email , ROW_NUMBER () OVER ( PARTITION BY Email ORDER BY RegistrationDate ASC ) AS rn FROM Customers WHERE Email IS NOT NULL ) DELETE FROM DuplicateCleaner WHERE rn > 1 ; -- ✅ Clean in-place deletion! 3. The Big Trap (Spooling Overhead): If you reference the same CTE multiple times in a query (e.g. CTE_A JOIN CTE_A ), SQL Server may execute the underlying CTE query multiple times or create a Lazy Spool in tempdb . -> Fix: For heavy multi-million row reuse, use a Temporary Table ( #TempTable ) with an explicit Clustered Index instead! 💡 How do you choose between CTEs, Temp Tables, and Subqueries in your pipelines? 💼 Connect on LinkedIn: linkedin.com/in/arpitmbangre

AI agents are becoming first-class citizens in developer workflows. They can read code, run tests, and deploy apps. But one thing they struggle with is understanding database schemas. Database design tools haven't changed in 20 years. You either use a heavyweight desktop app (Navicat, PDManer) or a pretty but closed web app (dbdiagram). Neither supports versioning, real-time collaboration, or AI agent integration. I built ERD Online to solve this. It's an open-source database design tool that combines Git-like versioning with Figma-like collaboration, plus MCP integration for AI agents. In this article, I'll show you how to let Cursor, Claude, or Cline read and write your database schema through MCP, while you keep full control. Database schema changes are hard to track: Who changed what? When did they change it? Why did they change it? How do I rollback? And now with AI agents, there's a new problem: how do you let an AI agent suggest schema changes without giving it a black box that generates random ER diagrams? The wrong approach: ask AI to "generate an ER diagram for an e-commerce app." You get a diagram, but it has no connection to your actual project, no versioning, and no approval flow. The right approach: let the AI agent read your existing schema, suggest changes, and submit them as a version that you review and approve. That's what ERD Online + MCP does. MCP (Model Context Protocol) is a protocol for AI agents to interact with external tools. Think of it as a USB-C port for AI applications. It standardizes how agents discover and call tools. MCP has three main primitives: Tools : Functions the AI can call (like list_projects or create_version ) Resources : Data the AI can read (like project.json ) Prompts : Pre-defined templates for common tasks ERD Online exposes MCP tools that let AI agents: list_projects : List all your ERD projects get_project : Get a project's projectJSON create_version : Suggest a new version of your schema The key boundary: AI agent

If you run ClickHouse in production, you're probably on 26.3 LTS. And now 26.8 LTS has been announced, which means the LTS-to-LTS upgrade conversation starts again. Here's the thing most release posts skip: this is not a one-release hop. Going from 26.3 LTS to 26.8 LTS means crossing 26.4, 26.5, 26.6 and 26.7 as well. Every breaking change in those four releases applies to you, and some of the ones most likely to ruin your day aren't in 26.8 at all. So instead of writing another "here are the 26.8 features" post, I wanted to write the thing I'd actually want before scheduling this upgrade: what breaks, what silently changes, what order to do things in, and what you get for the trouble. A note on release timing As of writing (27 August 2026), 26.8 has been announced but is not fully released yet. The release branch is cut and versioned (v26.8.1.1-lts), but the tag and Docker images have not been published yet, and the upstream changelog still marks the 26.8 section as in progress. By the time you read this, the tag has probably landed. Check for yourself: curl -s https://raw.githubusercontent.com/ClickHouse/ClickHouse/master/utils/list-versions/version_date.tsv \ | awk -F '\t' '$1 ~ /^v26\.8\./ {print "26.8 is released - newest: " $1 " (" $2 ")"; f=1; exit} END {if (!f) print "26.8 not released yet"}' version_date.tsv is the list ClickHouse maintains of every released version and its date, so this is the most direct answer available - no auth, no rate limit, nothing to download. As of writing it prints 26.8 not released yet . Worth knowing: the Docker image will lag whatever that command tells you. The Docker Official Images repo trails the GitHub tags by a few patch versions - clickhouse:lts currently resolves to 26.3.20.7 even though 26.3.24.4 has already shipped. So don't treat a missing image as evidence the release hasn't happened. Either way, the timing works in your favour. Historically ClickHouse LTS releases pick up several patch releases quickly - 26.7 had

Startups building B2B products reach for multi-tenancy in PostgreSQL the same way on day one: one shared database, one set of tables, and a tenant_id column marking who owns each row. That is the correct call, and it stays correct for a long time. However, when that column is enforced by application code rather than by the database, a single forgotten predicate stops being a bug and becomes a disclosure event, and a disclosure event is one of the very few engineering failures that lands straight on your balance sheet as stalled enterprise deals, an unplanned legal bill, and a security review you can no longer pass. By understanding what multi-tenancy actually guarantees, which isolation model fits your stage, and how Row-Level Security moves that guarantee out of your codebase, startup CTOs and Fractional CTOs can make the tenant boundary hold without slowing the team down. (If you want to skip the theory, jump straight to the connection pooler trap that switches Row-Level Security off in production, what it costs in query performance, or when it is genuinely time to leave the shared schema.) Because "enforced by application code" means something very specific in practice. It means a promise that everyone will remember to filter on tenant_id , and that promise is the single most expensive line of undocumented policy in your entire codebase, because it holds perfectly for about fourteen months, right up until the afternoon a tired engineer ships a reporting endpoint that joins four tables and forgets the predicate on exactly one of them, and then a customer opens a dashboard and sees somebody else's invoices. That is not a bug. A bug is something you fix on Monday. A cross-tenant data leak is a disclosure event, which means legal gets involved, your enterprise prospects get an email from their own security team, and the deal that was supposed to close your Series A quietly moves to next quarter and then to never. The uncomfortable part is that this is not a story abo

How I Built a Wedding Planning Suite with Supabase in 3 Months Quick Answer: I built a full wedding planning platform in 90 days using Supabase as the backend (PostgreSQL database, real-time subscriptions, Row Level Security, and OAuth auth), Next.js 14 for the frontend, and a few carefully chosen npm packages for specific features like QR code scanning. The key was leveraging Supabase's managed services to avoid building auth, websockets, and file storage from scratch. Introduction Three months ago, I had an idea: what if couples could plan their entire wedding through one cohesive platform? Not a static checklist app, but a living, breathing system where vendors, guests, budgets, and timelines all talked to each other in real time. I'm a solo developer with a day job. I didn't have a team of backend engineers to build authentication, real-time sync, or file storage infrastructure. I needed a stack that would let me ship fast without shipping broken. Enter Supabase. I'd heard the "Firebase alternative" pitch before, but what I discovered was something far more powerful for developers who actually want to own their data and their SQL. This is the story of how I built WedPlanner—a full wedding planning suite—with Supabase, Next.js, and a few other tools. No VC funding. No offshore team. Just me, a tight deadline, and a PostgreSQL database that never let me down. Why Supabase? The Architecture Decision That Made Everything Possible When you're building alone, every architectural decision compounds. Pick the wrong database, and you'll spend weeks fighting migrations. Pick the wrong auth solution, and you'll ship with security holes you don't even know about. I evaluated Firebase, PlanetScale, Clerk, and rolling my own PostgreSQL on RDS. Here's why Supabase won: PostgreSQL, not a proprietary document store. Wedding data is relational. A guest belongs to a wedding. A vendor has multiple bookings. A budget category has many line items. Trying to model this in Firestore's

The lakehouse projects spent this week arguing about boundaries. Iceberg decided where conformance testing lives and started sketching the REST API shape that V4 tables will need. Polaris argued about what a committer owes a project when LLMs make pull requests cheap. Parquet pulled a feature apart because two proposals were reaching for the same mechanism. DataFusion and Iceberg Rust opened a joint thread about which repository should own their integration. Every one of those debates is a question about ownership, and the answers this week tell you a lot about how these communities plan to scale. Apache Iceberg The single biggest outcome of the week was the creation of a new repository. Neelesh Salian, working with Sung Yun and Andrei Tserakhau, called a vote to create apache/iceberg-verification , a standalone home for language-neutral conformance fixtures that every Iceberg implementation can run against. The vote passed with five binding +1s from Russell Spitzer, Sung Yun, Matt Topol, Daniel Weeks, and Amogh Jahagirdar, plus twenty-two non-binding votes. That is a wide turnout. The names on the non-binding list read like a roll call of the Rust, Python, Go, and Java maintainers, which is the point. Salian will now work with a PMC member to stand the repository up. The reason this matters goes beyond tidiness. Iceberg has at least five serious implementations today across Java, Python, Rust, Go, and C++. Each one carries its own test fixtures and its own understanding of edge cases in the spec. When two implementations disagree about how to interpret a manifest list, users find out the hard way. A shared set of fixtures that every implementation reads from one place turns spec ambiguity into a failing test rather than a production surprise. The 29 messages in the vote thread also included a fair amount of discussion about what belongs in the first batch of fixtures, and the conversation is worth reading if you maintain a client. The second major thread was about

Most LlamaIndex setups end up with two separate backends once you go beyond plain vector search: a vector store for VectorStoreIndex , and a separate graph database for PropertyGraphIndex when you need relationship-aware retrieval (GraphRAG). Two services, two connection strings, two things to keep in sync. This is a walkthrough of backing both index types with SynapCores instead — one engine, one connection, both index types. Setup docker run -d --name synapcores -p 8080:8080 \ -e AIDB_ACCEPT_LICENSE = 1 \ -v synapcores-data:/var/lib/synapcores \ ghcr.io/synapcores/community:latest pip install llama-index llama-index-vector-stores-synapcores llama-index-graph-stores-synapcores Both integration packages are independently published on PyPI: llama-index-vector-stores-synapcores llama-index-graph-stores-synapcores Vector store — standard RAG from llama_index.core import VectorStoreIndex , StorageContext , Document from llama_index.vector_stores.synapcores import SynapCoresVectorStore vector_store = SynapCoresVectorStore ( uri = " http://localhost:8080 " , embedding_dim = 1536 ) storage_context = StorageContext . from_defaults ( vector_store = vector_store ) docs = [ Document ( text = " SynapCores runs vector search, graph traversal, and SQL in one engine. " )] index = VectorStoreIndex . from_documents ( docs , storage_context = storage_context ) query_engine = index . as_query_engine () response = query_engine . query ( " What does SynapCores combine into one engine? " ) print ( response ) The vector store implements the full BasePydanticVectorStore ABC — add , delete , query , delete_nodes , clear , plus the async surface. Metadata filtering supports the full MetadataFilters grammar: all 12 operators ( EQ , NE , GT / GTE / LT / LTE , IN , NIN , TEXT_MATCH , TEXT_MATCH_INSENSITIVE , CONTAINS , IS_EMPTY ) with AND / OR / NOT and nested groups — so you're not giving up filtering power by moving off a dedicated vector DB. If you already have data in SynapCores from a prev

Today's two tasks are both about a new base. A feature branch that needs to sit on top of a master that has moved. A database instance that needs to come back from a snapshot taken when things were fine. In each case, the interesting question is the same: what carries over, and what do you have to say out loud? One Git task, one AWS task. Rebase a feature branch onto master without creating a merge commit, then snapshot an RDS instance and restore it into a new one. The tasks come from the KodeKloud Engineer platform. Rebase: not moving commits, replaying them The requirement was specific, and the specificity is the lesson. A developer's feature branch was behind master. Bring it up to date without losing any feature work, and without a merge commit. That second clause rules out git merge master . Merge joins two histories and records the join, which is the merge commit. Rebase does something else entirely. cd /usr/src/kodekloudrepos/media git branch git log --oneline --graph --all --decorate git checkout feature git rebase master git log --oneline --graph --decorate Git's own documentation describes what happens under git rebase master : it lists the commits on your branch that are not on master, checks out master, and then replays each of your commits on top of it, one at a time, in a way it compares to running git cherry-pick for each one. Replays. Not moves. Every commit that comes out the other side has a new hash, because a commit's identity includes its parent, and the parent is different now. Your work is preserved, the commits carrying it are not the same objects they were. That is exactly why there is no merge commit. Rebase does not join two histories, it rewrites yours so it looks like it was always based on master's current tip. You get a straight line, at the cost of a history that is no longer a record of what actually happened. Two things I had to be deliberate about. Direction. Rebase applies to the branch you are standing on and takes the branch yo

O NutriApp é um projeto de estudos: plataforma de saúde conectando pacientes, nutricionistas, médicos e personal trainers, cada perfil enxergando só o que sua permissão libera. Stack: React 19 + TypeScript, TanStack Start (SSR, rotas file-based e server functions), Tailwind v4 + shadcn/ui, react-hook-form + Zod para formulários tipados, TanStack Query para cache, e Lovable Cloud (Supabase) com Postgres e Row Level Security. O maior desafio foi o controle de acesso por papéis. Três tabelas centrais — profiles, user_roles e pacientes — todas com RLS ativado. Paciente lê só seus próprios registros; profissionais e administradores enxergam todos os pacientes. Pra evitar recursão de política (problema clássico de RLS), criei funções SECURITY DEFINER como has_role e is_profissional, quebrando o ciclo de verificação. Autenticação e segurança: Login por email/senha, com rota administrativa separada (/admin/login) Server functions protegidas com requireSupabaseAuth, checando papel antes de qualquer ação administrativa Validação client-side com Zod: senha entre 6-72 caracteres, email até 255, telefone opcional Usuários criados por admin já nascem confirmados e ativos, reduzindo fricção operacional Automação como diferencial: o perfil de saúde calcula IMC em tempo real e gera um plano inicial baseado no objetivo selecionado (emagrecimento, ganho de massa ou controle de patologias) — reduzindo trabalho manual do profissional. Aprendizados principais: RLS bem modelado desde o início evita gambiarra depois — pensar em papéis antes da primeira quere economiza retrabalho. Verificação de papel precisa estar no backend, nunca só na UI. Separar login de paciente/profissional do login admin simplifica segurança e UX ao mesmo tempo.

The schema catalog for an AI assistant is the artefact that answers the question "what does this database look like right now". Whether the database is Postgres, MySQL, SQL Server or Redshift, the shape of the problem is the same: the catalog carries table names, column names, types, keys, and enough relationships to let the assistant write a query that resolves. It lives somewhere between the database and the assistant, has to stay in sync with a database that changes underneath it, and is almost always built the same weekend the team decides they want an AI assistant reading their data. It runs fine for the first three tables. The problems start around the fourth week, and none of them look like the same problem twice. The distinction worth naming early is between the connection layer (how the assistant reaches the database) and the knowledge layer (what the assistant knows about the database's shape). The connection layer receives most of the attention, because credentials, network isolation and query cost are visible failure modes and easy to argue about. The knowledge layer is where most of the actual quality of the assistant lives, and it decays quietly. The AI database context page covers why this second layer matters at all when the first one exists. Why not just point the assistant at the database Connecting the AI directly to production is the shortest path and the one most teams reject after five minutes of thinking about it. The assistant would get read access on tables it should not see, its queries can be arbitrarily expensive, its credentials would live somewhere they should not, and the audit trail becomes hard to reason about. What most teams end up building is a layer in between: a representation of the database that the assistant can read cheaply and safely without ever touching production. That layer is what this article is about. It is not the connection. It is the catalog. The five recipes teams build Ask fifteen senior developers how to build

The company says it will start construction in 2027 and that a Starship rocket could take flight as soon as 2029.

I’ve been building a small open-source TypeScript toolkit called Tenant Evidence Kit for private, multi-tenant evidence workflows on Supabase. The project started from a very specific problem: How do you attach photos, documents, or other evidence to a business object without making files public, leaking tenant data, or duplicating authorization logic across the application? The toolkit keeps that infrastructure deliberately small and domain-agnostic. It currently provides: private Supabase Storage; evidence metadata separated from file bytes; tenant isolation with Row Level Security; short-lived signed URLs; compensating cleanup when metadata persistence fails; reference migrations for tenant membership and evidence authorization. But the interesting part of the latest release was not the original implementation. It was the review loop. A community review found real problems I shared the project with the Supabase community and received a detailed security review. The feedback raised several important questions: roles existed, but authorization was still too close to flat membership; evidence deletion needed a more explicit privilege boundary; the lack of UPDATE support needed to be intentional rather than accidental; RLS assumptions around service_role , table owners and BYPASSRLS needed to be documented; authorization needed behavioral tests, not only static SQL assertions. That feedback was good enough that I didn’t want to treat it as a documentation exercise. I turned it into an implementation task. Using Codex as the implementation loop Instead of asking Codex something broad like: “Improve the security.” I gave it a tightly scoped issue with explicit acceptance criteria. The workflow became: community review → scoped issue → Codex implementation → human review → correction pass → CI → release The first implementation was useful, but the review still found problems. For example, it initially changed existing INSERT behavior and modified only the original migra