Drizzle ORM is a headless, type-safe SQL query builder and ORM for TypeScript/JavaScript, supporting PostgreSQL, MySQL, SQLite, and serverless databases (Neon, PlanetScale, Cloudflare D1, Turso, etc.). The repository is a monorepo containing the core ORM library (`drizzle-orm`), a CLI tool (`drizzle-kit`) for schema introspection, migration generation, and database push/pull, a data seeding library (`drizzle-seed`), validation schema generators (`drizzle-zod`, `drizzle-valibot`, `drizzle-typebox`, `drizzle-arktype`), and an ESLint plugin (`eslint-plugin-drizzle`). The architecture follows a dialect abstraction pattern: each database has its own column builders, query builders (select, insert, update, delete), and session implementations that wrap native client libraries. The core provides composable SQL building via template literals, runtime type identification via the `entityKind` pattern, and a caching layer with tag-based invalidation. The CLI uses Zod-based configuration validation and generates migration SQL by diffing serialized schema snapshots. Integration tests run against real databases in Docker containers, and extensive type tests ensure compile-time correctness. External dependencies include various database client libraries (pg, mysql2, better-sqlite3, libsql, @neondatabase/serverless, etc.) and validation libraries (zod, valibot, typebox, arktype).
claude-mem is a persistent memory system for AI coding assistants, primarily targeting Claude Code but also supporting Codex, Cursor, Windsurf, OpenClaw, and other platforms. It captures observations, summaries, and user prompts from coding sessions via lifecycle hooks (SessionStart, PostToolUse, etc.), stores them in SQLite (local) or Postgres (server), and injects relevant context into future sessions to maintain continuity across agent interactions. The system operates as a background worker daemon (Bun) or a multi-user server (Express + BullMQ + Valkey) with API key authentication, team/project scoping, and rate limiting. Architecturally, claude-mem is a hybrid of a CLI plugin and a standalone server. The CLI component integrates into IDEs via hook scripts and MCP servers, while the server component provides REST APIs for memory management, search, and cloud sync. It features a dual-storage backend (SQLite for local, Postgres for server) with vector search via ChromaDB and full-text search via SQLite FTS5. The system includes a React-based viewer for browsing memory feeds, telemetry (opt-out PostHog), and a Cloudflare Workers-based sync hub for cross-device synchronization. The codebase demonstrates strong engineering practices with well-abstracted components (search strategies, provider abstraction, atomic file operations, telemetry scrubbing) but carries some technical debt from its dual-runtime evolution (legacy worker vs. server-beta) and extensive Windows-specific workarounds. It is actively maintained with frequent releases and comprehensive test coverage.
Coolify is a self-hosted Platform-as-a-Service (PaaS) that enables users to deploy and manage applications, databases, and services on their own infrastructure. It serves as an open-source alternative to Heroku, Netlify, or Vercel, supporting Docker-based deployments with Git integration (GitHub, GitLab, Gitea, Bitbucket), multiple build packs (Railpack, Nixpacks), and one-click service templates. The system manages servers, reverse proxies (Traefik/Caddy), SSL certificates, scheduled backups, and multi-channel notifications (email, Discord, Slack, Telegram, Pushover, webhook). The architecture is a Laravel monolith with a Livewire + Alpine.js frontend for the v4 UI and a React + TypeScript canvas-based interface for the v5 UI. Background jobs are handled by Laravel Horizon with dedicated queues for deployments, cron tasks, and reconciliation. Real-time updates use Soketi (a Pusher-compatible WebSocket server) and Laravel Echo. The system integrates with cloud providers (Hetzner, Vultr, DigitalOcean) for server provisioning and Stripe for subscription billing. A Model Context Protocol (MCP) server exposes resources and tools for AI assistant integration. Key data flows include: webhook ingestion from Git providers triggering deployment jobs, SSH-based remote command execution on managed servers, Docker Compose parsing and environment variable injection, database backup scheduling with S3 storage, and proxy configuration generation. The v5 architecture introduces a control-plane/agent split with Flux (HTTP socket) and coold (gRPC) components for improved scalability and isolation. External dependencies include Docker, PostgreSQL, Redis, Soketi, Stripe API, cloud provider APIs, and various notification service endpoints. The codebase is actively developed with frequent schema migrations and a dual v4/v5 code path, indicating ongoing architectural evolution.
pREST is a production-grade Go HTTP server that automatically exposes PostgreSQL databases as RESTful and MCP (Model Context Protocol) APIs without requiring hand-written backend code. It provides instant CRUD endpoints for any table, custom SQL template execution with parameterized queries, and a built-in Studio web UI for exploring and managing APIs. The system is architected around a hexagonal pattern with a clean adapter interface supporting multiple databases (PostgreSQL, TimescaleDB), dependency injection for controllers, and a layered middleware stack for authentication (JWT), authorization (table/field-level ACL), caching, and CORS. Security is a primary concern: SQL injection is mitigated through strict identifier validation, template parameter screening, and bound parameter binding, while credential leakage in logs is prevented by a dedicated redaction package. The codebase is well-tested with both unit tests (using sqlmock) and integration tests (against real PostgreSQL in Docker), and includes OpenTelemetry integration for observability. It is not a data research or analytics project; it is a pure application for building low-code database APIs.
PGO (Crunchy Data Postgres Operator) is a production-grade Kubernetes operator that manages the full lifecycle of PostgreSQL clusters, including deployment, high availability via Patroni, backup/restore via pgBackRest, connection pooling via PgBouncer, monitoring via OpenTelemetry and pgMonitor, and a web UI via pgAdmin. The operator uses custom resource definitions (CRDs) for PostgresCluster, PGAdmin, and PGUpgrade, and reconciles desired state using controller-runtime with server-side apply. It manages StatefulSets, PVCs, Services, ConfigMaps, Secrets, Jobs, and RBAC across multiple namespaces. Architecturally, the operator is a single binary with multiple controllers (postgrescluster, standalone_pgadmin, pgupgrade) and sidecar containers for pgBackRest, PgBouncer, pgAdmin, and the OpenTelemetry collector. It uses feature gates to enable optional capabilities like volume snapshots, auto-grow volumes, and OpenTelemetry logging/metrics. The codebase is well-structured with distinct packages for naming conventions, PKI certificate management, PostgreSQL parameter management, and shell command construction. Extensive unit and e2e tests (using kuttl and chainsaw) cover most scenarios, including backup/restore, scaling, upgrades, and security contexts. Key external dependencies include controller-runtime, client-go, Patroni, pgBackRest, PgBouncer, pgAdmin, OpenTelemetry SDK, and pg_query_go for SQL parsing. The operator is deployed via Kustomize and supports multiple PostgreSQL versions (11-18) with PostGIS extensions.
Hasura GraphQL Engine is an open-source, metadata-driven GraphQL server that provides instant, real-time GraphQL APIs over multiple databases (PostgreSQL, MSSQL, BigQuery, CockroachDB, Citus, and custom sources via Data Connectors). The repository is a large monorepo containing a Rust-based v3 engine, a Go CLI for project management (migrations, metadata, seeds), a React/TypeScript admin console, and community boilerplates for authentication, event triggers, and remote schemas. The system exposes a single GraphQL endpoint that supports queries, mutations, subscriptions, streaming subscriptions, event triggers, cron triggers, remote joins, actions, and Apollo Federation. It relies on external databases, webhook endpoints for auth and event handling, and optionally OpenTelemetry collectors for observability. The architecture is modular: the v3 engine handles metadata resolution, GraphQL schema generation, and execution planning; the CLI manages project lifecycle; and the console provides a GUI for configuration. The codebase is actively maintained with frequent releases, but shows signs of technical drift due to legacy frontend code (Redux vs React Query), dual version support (v2/v3), and multiple programming languages (Rust, Go, TypeScript, Haskell, Python).
CloudNativePG is a Kubernetes operator for managing PostgreSQL databases in production. It automates deployment, failover, scaling, backups, upgrades, and connection pooling (PgBouncer) through custom Kubernetes resources (CRDs) and reconciliation loops. The operator consists of two binaries: a manager that runs inside pods to manage PostgreSQL instances, and a kubectl plugin for administrative commands. The architecture is modular with separate reconcilers for clusters, instances, backups, roles, tablespaces, and replication slots. It includes a plugin system (CNPG-I) for extensibility via gRPC, a web server for health probes and metrics, and a Prometheus exporter for monitoring. The codebase is written in a non-standard Go dialect (using URL-like import paths, func keyword, and var type declarations), which may indicate a custom transpiler or DSL. Despite this, the project is production-grade with extensive unit and end-to-end tests, active maintenance, and support for multiple Kubernetes distributions (kind, k3d, OpenShift).
This repository provides a production-ready, full-stack Retrieval-Augmented Generation (RAG) chat application built with Python FastAPI and React TypeScript. It demonstrates how to use Azure OpenAI (or OpenAI.com, or Ollama) to answer questions about data stored in Azure Database for PostgreSQL with the pgvector extension. The system supports both a simple RAG flow (embedding + direct search) and an advanced flow that uses OpenAI function calling to rewrite queries and apply column filters (brand, price). It features hybrid search combining full-text search and vector similarity via Reciprocal Rank Fusion. The backend is a monolith serving API endpoints and a React frontend, designed for deployment to Azure Container Apps using the Azure Developer CLI. The codebase includes comprehensive unit tests, end-to-end tests with Playwright, evaluation scripts, load testing with locust, and safety evaluation using Azure AI Red Teaming. The architecture is cleanly separated into reusable modules, making it a solid reference architecture for building RAG applications on Azure.
Equinox is an F# library for event-sourced systems, providing a consistent abstraction over multiple stream-based storage backends including CosmosDB, DynamoDB, EventStoreDB, MessageDB, SqlStreamStore, and an in-memory store. In production, it enables applications to define domain logic as pure decision functions that produce events, while the library manages optimistic concurrency, caching, snapshots, and retries. The core is the `Decider` pattern: an aggregate loaded from a stream, a decide function that returns events, and a fold that applies events to produce new state. Access strategies (e.g., `LatestKnownEvent`, `RollingSnapshots`, `Custom`) control how state is reconstructed from stored events, trading read cost for write cost. The architecture is modular: the `Equinox` package defines the core interfaces (`ICategory`, `IStream`, `Decider`), while separate NuGet packages implement storage adapters. The library is used as a dependency in larger applications; sample projects (`Store/Domain`, `TodoBackend`, `Tutorial`) demonstrate its use. Key entry points include the `Decider` class for command/query execution, `Category` for resolving streams, and store-specific connectors (e.g., `CosmosStoreConnector`, `DynamoStoreConnector`). A CLI tool (`Equinox.Tool`) provides provisioning, benchmarking, and data inspection commands across all stores. External dependencies are minimal per package: `Equinox` depends only on `FsCodec` for serialization; store adapters require their respective SDKs (Azure.Cosmos, AWSSDK.DynamoDBv2, EventStore.Client, Npgsql, etc.). The library includes comprehensive caching (`Equinox.Cache` wrapping `System.Runtime.Caching.MemoryCache`), metrics via Prometheus, and a load testing harness. Despite some deprecated adapters (legacy EventStore TCP, SqlStreamStore) and high complexity from multiple backends, the core patterns are clean, well-tested, and production-proven at Jet.com.
Activeloop's DeepLake is a production-grade, multi-vector database engine for AI data. At its core, it is a columnar, chunked, compressed storage system for tensors (multi-dimensional arrays) with native support for embeddings, images, video, text, and other complex AI data types. It exposes a Python library for dataset management, ingestion (COCO, Labelbox, CSV, Parquet), version control, and integration with PyTorch/TensorFlow/MMDetection. A high-performance C++ backend provides lazy NumPy-like array operations (nd::array), a composable async framework (async::promise), and a Tensor Query Language (TQL). The most distinctive component is a PostgreSQL extension (pg_deeplake) that allows SQL access to DeepLake datasets via custom table and index access methods, supporting vector similarity search (cosine, BM25) and hybrid search. Query execution is delegated to DuckDB through a custom scan node, enabling efficient analytical queries. The extension also includes WAL-based DDL replication across instances. This is primarily an application (a database system), with substantial research-oriented features such as medical image formats, compression codecs, and TPC-H benchmarking.
Jitsu is an open-source event data platform (alternative to Segment) that ingests events from websites, apps, and servers, transforms them via user-defined functions (UDFs) and built-in destination functions, and delivers them to data warehouses (ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS) and SaaS tools (Amplitude, PostHog, HubSpot, etc.). The architecture is multi-service: a Go-based bulker handles ingestion and warehouse delivery, a TypeScript-based rotor executes event transformations and profile building, a Next.js console provides the management UI and API, and a CLI tool supports project management and function deployment. The data flow is: HTTP ingest → Kafka → rotor (functions) → bulker (SQL/file destinations) → ClickHouse/PostgreSQL for metrics and logs. External dependencies include Kafka, PostgreSQL, ClickHouse, Redis, MongoDB, and Google Cloud Storage. The console supports multi-tenant workspaces, authentication (Firebase, OIDC, NextAuth), billing, audit logging, rate limiting, and an MCP server for AI tool integration. The codebase is a monorepo with pnpm workspaces and Go modules, featuring extensive test suites (unit, integration with testcontainers, e2e) and CI/CD pipelines. It demonstrates strong engineering practices with reusable libraries (juava, jitsubase), custom high-performance JSON parsers, and well-abstracted repository and configuration patterns. However, there is some technical drift: duplicate JSON libraries (jsoniter and jsonorder), commented-out code, and ESLint disable comments in admin routes. Overall, it is a mature, actively maintained platform suitable for production use.
porsager/postgres is a PostgreSQL client library for Node.js, Deno, and Cloudflare Workers. It provides a full-featured, performant interface to PostgreSQL using tagged template literals for safe, parameterized queries. The library implements the PostgreSQL wire protocol from scratch with zero runtime dependencies, supporting advanced features like connection pooling, prepared statements, cursors, COPY streams, logical replication, large objects, and custom type mapping. The architecture is a factory function that returns a `sql` tagged template function, which lazily connects to the database and pipelines queries over persistent connections. The codebase is well-structured across `src/` with separate modules for connection management, query execution, protocol message building, type serialization/parsing, and error handling. It also includes transpiled builds for CommonJS, Deno, and Cloudflare Workers, each with platform-specific polyfills. The library is actively maintained, has extensive test coverage, and is published under a public domain license.
This repository is the personal blog and knowledge base of digoal, a prominent PostgreSQL DBA and database expert. It contains over a decade of blog posts (2010–2026) covering PostgreSQL internals, performance tuning, database architecture, and related topics, along with a large collection of images, PDFs, and other attachments. The blog is organized by year and month, with each post as a markdown file. The repository also includes a 'skills' directory that defines reusable AI agent skill definitions (SKILL.md files) for various tasks such as fact-checking, stock prediction, bug hunting, and course writing. These skills are structured with agent prompts, reference materials, and supporting scripts, making them extractable and reusable in AI-assisted workflows. The repo is actively maintained and serves as both a reference for database professionals and a library of AI agent capabilities.
This repository is a production-grade FastAPI boilerplate (named 'Fastro') designed to accelerate building SaaS backends. It provides a complete, modular architecture with three layers: infrastructure (config, caching, rate limiting, auth, logging, database), interfaces (REST API, admin panel), and vertical-slice modules (user, tier, API keys, rate limits). The codebase is fully async, uses SQLAlchemy 2.0 with `MappedAsDataclass`, Pydantic v2, and FastCRUD for generic CRUD operations. Authentication is session-based via the external `crudauth` library, with server-side sessions, CSRF, OAuth (Google wired), and API key support. Caching and rate limiting follow a provider pattern with swappable Redis/Memcached backends. The repo also includes a CLI tool (`bp`) with plugin discovery for commands and features, a multi-stage Dockerfile, Alembic migrations, and extensive documentation (though some docs describe aspirational features not yet implemented). A paid fork (FastroAI) adds payments, email, and frontend, but the free boilerplate is self-contained and functional.
Supermemory is a commercial-grade AI memory and context engine that provides persistent long-term memory for AI agents. The repository implements the client-side integration SDKs, an MCP (Model Context Protocol) server, a memory graph visualization component, and supporting infrastructure. In production, it connects to an external cloud API (api.supermemory.ai) that handles document ingestion, semantic search, user profiles, and knowledge graph construction. The codebase is organized as a monorepo with distinct packages for TypeScript/Python SDKs covering multiple AI frameworks (Vercel AI SDK, OpenAI, Mastra, Claude, etc.), a Cloudflare Workers-based MCP server with OAuth and widget UI, a ship-grade memory-graph React component with force-directed canvas rendering, and a comprehensive validation schema package. The architecture demonstrates strong engineering practices: strict Zod validation, middleware injection patterns, caching and deduplication logic, and thorough testing across languages. Notable skill is evident in the memory-graph canvas engine (viewport, simulation, spatial indexing, version chain visualization) and the shared memory-context injection utilities. The main downside is significant logic duplication across four Python SDK packages and their TypeScript counterparts, which increases maintenance risk. The repo is actively developed with CI/CD pipelines publishing to npm and PyPI.
Redka is a Redis-compatible data store implemented in Go, using SQLite or PostgreSQL as the storage backend. It reimplements core Redis data structures (strings, lists, sets, hashes, sorted sets) with full TTL support, key scanning, and set/sorted-set aggregation operations. The system can be deployed either as an embedded Go library (via the `redka` module) or as a standalone RESP-compatible server (single binary or Docker image). Architecture follows a clean layered design: a top-level `DB` struct provides transactional access to per-type repositories (e.g., `ZSet()`, `Hash()`), which in turn use a dialect abstraction layer (`sqlx`) to generate SQLite- or PostgreSQL-specific queries. The RESP server is built on `tidwall/redcon` with a command dispatch pattern and a reusable parser combinator framework for argument parsing. While feature-complete for core Redis operations, the project is explicitly in maintenance mode—no new features are planned, and documentation notes incomplete command coverage (e.g., blocking operations, some sorted set commands). The codebase is well-structured with extensive test coverage, but Postgres support shows signs of drift (many queries aliased to SQLite) and the command dispatch switch has grown large.
Totum is a self-hosted, low-code/no-code application framework built on PHP 8.3 and PostgreSQL. It functions as a dynamic database and spreadsheet hybrid, allowing users to define data structures (tables, fields) via JSON configuration and implement business logic using a proprietary DSL ('Totum-code'). The system features a modular architecture with a CLI management tool (`bin/totum`), a web-based UI (`http/index.php`), and extensive role-based access control (RBAC). It supports multi-tenancy via schema mapping, external service integration (PDF, Excel, AI), and automated installation via Ansible playbooks for Ubuntu environments. The core logic relies heavily on traits for shared functionality and abstract base classes for table and field handling, creating a flexible but complex codebase. The application is designed for rapid business application construction (CRM, ERP, custom tools) without requiring traditional coding. It stores schema definitions and field configurations in PostgreSQL JSONB columns, enabling runtime structure modification. The calculation engine (`Calculate.php`) parses and executes custom code strings for data validation, formatting, and cross-table logic. While the architecture is robust for its intended purpose, it exhibits signs of technical debt including monolithic frontend JavaScript (`main.js`), hardcoded paths in installation scripts, and reliance on legacy libraries (Chart.js v2, jQuery). The codebase demonstrates significant craftsmanship in its dynamic table engine and calculation DSL, but maintenance requires careful handling of the custom parsing logic and schema migrations.