Piccolo is an async-first Python ORM and query builder targeting PostgreSQL, SQLite, and CockroachDB. It provides a declarative table definition system, automatic schema migrations, a CLI for project scaffolding, user authentication, fixture dump/load, and Pydantic model generation. The codebase is well-structured with clean abstractions (column types, query delegates, engine abstraction, migration auto-generation) and an extensive test suite covering multiple database backends. It is actively maintained with frequent releases and supports recent Python and database versions.
This repository is the official FastAPI full-stack template, providing a production-ready starter for full-stack web applications. It consists of a FastAPI backend (Python 3.14, SQLModel ORM, PostgreSQL, Alembic migrations) and a React frontend (TypeScript, Vite, TanStack Router/Query, Tailwind CSS, shadcn/ui). The template ships with complete authentication (JWT, password hashing with Argon2/Bcrypt, password recovery via email), user and item CRUD, role-based access control, and a responsive dashboard UI. Deployment is handled via Docker Compose with Traefik, and the project includes comprehensive CI/CD pipelines for testing (pytest, Playwright) and deployment (FastAPI Cloud or self-hosted). While it is a template, the code is structured for immediate extension and includes many reusable patterns such as generic CRUD utilities, email templates written in React Email, and auto-generated OpenAPI client code for the frontend. The repository is not a data research project; it is a pure application template with no data pipelines, notebooks, or ML components. It is actively maintained, with frequent commits and a strong community following.
This is the Supabase JavaScript SDK monorepo, providing isomorphic client libraries for Supabase backend services. It is a well-structured TypeScript monorepo managed with pnpm and Nx, containing six core packages: auth-js (authentication), postgrest-js (database queries via PostgREST), realtime-js (WebSocket-based realtime subscriptions), storage-js (file storage and vector index API), functions-js (edge function invocation), and the umbrella supabase-js package that combines them into a single `createClient()` entry point. The SDK supports multiple runtimes (Node.js, Deno, browsers, Bun, React Native, Cloudflare Workers) and includes optional OpenTelemetry tracing support. The codebase demonstrates high craftsmanship with extensive TypeScript generics for type-safe query building, fluent builder patterns, robust error handling hierarchies, and comprehensive integration tests against local Supabase infrastructure. It is actively maintained with frequent releases, automated CI/CD, and a strong focus on backward compatibility.
Paperclip is a full-stack, self-hostable platform for orchestrating AI agents in a work management context. The server (Node.js/Express + PostgreSQL) provides a control plane for hiring agents (Claude Code, Codex, Cursor, Gemini, etc.), assigning tasks (issues), enforcing budgets and approvals, and managing workspaces. A Rust native runner executes agent sessions with a rich protocol, while adapters bridge to each AI provider's specific APIs. The React UI offers dashboards, task boards, agent management, and administrative features. The monorepo also includes a CLI, plugin SDK, MCP servers, extensive E2E/unit test infrastructure, and a skills catalog. While primarily an application, the repository contains data-intensive subsystems like telemetry collection, cost tracking, and a decision-training example store that blur into data engineering.
SparkyFitness is a large, self-hosted fitness and health tracking platform. It is primarily an application: a full-stack monorepo with an Express + PostgreSQL backend, a React web frontend, a React Native/Expo mobile app, and a Python FastAPI Garmin microservice, all coordinated by a shared TypeScript package containing Zod schemas, constants, and domain algorithms. The product covers nutrition, workouts, sleep, fasting, mood, cycle/pregnancy, medications, symptoms, water intake, mindfulness, and health-provider data from Garmin, Fitbit, Withings, Oura, Polar, Strava, Google Health, and others. It also includes an AI chatbot with tool calling, barcode scanning, CSV/FIT imports, and native HealthKit/Health Connect sync. The dominant data flow is client hooks calling typed API service layers, which hit Express routes backed by PostgreSQL with row-level security. External wearable integrations refresh OAuth tokens under row locks and use provider sync claims to avoid duplicate imports. The mobile clients also directly read/write platform health stores, and a large migration set evolves the schema with careful backfills and deduplication. The repository is not a data-research repo; there are no analytical notebooks or dbt-style pipelines. Its character is clearly a production application with an unusually wide feature surface. The codebase shows strong engineering discipline: shared Zod schema triples, consistent TanStack Query key factories, central cache invalidation hubs, provider sync concurrency controls, and extensive Vitest/Jest tests, including regression tests pinned to GitHub issue numbers. The main risks are breadth-driven complexity: many external integrations, native iOS/Android/watch targets, manual patches to generated schemas, and some duplicated logic across web and mobile. Overall it is actively maintained, well-tested, and offers several genuinely reusable patterns.
TablePro is a native macOS and iOS database client built with SwiftUI and AppKit, designed as an open-source alternative to commercial tools like TablePlus. It supports a vast array of database engines (PostgreSQL, MySQL, MSSQL, Oracle, MongoDB, Redis, Snowflake, ClickHouse, DuckDB, Teradata, Trino, etc.) through a plugin-based driver architecture defined in TableProPluginKit. The application features a custom code editor (CodeEditSourceEditor) with tree-sitter syntax highlighting, line folding, minimap, and Vim mode; a powerful data grid for inline editing; SSH tunneling with multi-factor authentication; CloudKit-based sync for connections and settings; and an integrated AI assistant with MCP (Model Context Protocol) server support for agentic database interactions. The codebase is actively maintained, demonstrates high engineering craftsmanship with clean protocols, extensive unit and UI tests, and many reusable components that could be extracted into independent libraries.
Slonik is a mature, battle-tested PostgreSQL client library for Node.js, designed with a strong emphasis on type safety, runtime validation, and extensibility. It is structured as a monorepo with multiple packages including the core `slonik` library, `@slonik/sql-tag` for building SQL queries via tagged template literals, `@slonik/errors` for a rich error hierarchy mapping PostgreSQL error codes, `@slonik/driver` and `@slonik/pg-driver` for abstracted database connectivity, and ecosystem packages like interceptors (logging, caching, field name transformation) and dataloaders for GraphQL-style batching and cursor pagination. The library enforces strict query result assertions (e.g., `one`, `many`, `maybeOne`) and integrates with Zod for runtime schema validation of query results. Its architecture revolves around an interceptor pattern that hooks into the query lifecycle (before/after query execution, row transformation, connection events), enabling powerful middleware without modifying core logic. The connection pool features advanced capabilities such as idle timeout, maximum connection age, minimum pool size, warmup, and graceful termination. Slonik is ESM-only since v48.0.0 and requires Node.js >=24. It is actively maintained with frequent releases, comprehensive test coverage (unit and integration tests using Docker), and a benchmark suite comparing performance with other PostgreSQL clients.
This repository is a distribution of the classic 'employees' sample database, a realistic relational dataset of ~300,000 employees, ~2.8 million salary records, and associated department/title/manager data. It is not an application but a data asset and benchmark fixture used to test database servers, application integrations, and migration tooling. The repo contains MySQL and PostgreSQL schemas, raw data dumps, partitioned table variants, stored procedures/views, and an integrated integrity-test suite that verifies row counts and incremental MD5/SHA-1/SHA-256 checksums. It also bundles a version of the Sakila sample database. CI workflows exercise loading and integrity checks across MySQL 5.6-9.6, Percona Server, MariaDB, and PostgreSQL 16/17, and the SHA-256 checksums are intentionally identical across all supported engines. The primary value is a non-trivial, self-contained dataset with strong cross-database compatibility and a clever, reusable data-integrity verification pattern.
This repository is a comprehensive French-language training course for PostgreSQL 18, structured as 22 progressive chapters and 7 reference annexes. It serves as educational material covering PostgreSQL fundamentals, SQL querying, advanced features, administration, performance tuning, extensions, and modern architectures. The content combines theoretical explanations with practical examples, best practices, and version-specific features (like asynchronous I/O, UUIDv7, and native OAuth). While not containing executable code or data pipelines, it provides reusable reference materials such as SQL query templates, shell scripts for backup/monitoring, configuration guides, and checklists that can be adapted across projects. The repository is actively maintained with recent updates and demonstrates low technical drift due to its focus on enduring database principles alongside version-specific annotations.
Medoo is a lightweight PHP database framework that provides a fluent, array-based API for building SQL queries and mapping results. It supports multiple database engines (MySQL, PostgreSQL, SQLite, MSSQL, Oracle, Sybase) via the PDO extension. The library is contained in a single source file (src/Medoo.php) and offers CRUD operations, joins, aggregates, raw SQL, transactions, and column type mapping. It is designed to be simple and intuitive, fitting naturally into various PHP frameworks. The codebase includes a comprehensive test suite that validates SQL generation across different database dialects, and the project is actively maintained with modern PHP version support.
This repository provides **pgrx**, a framework for writing PostgreSQL extensions entirely in Rust. It includes a CLI tool (`cargo-pgrx`) for project scaffolding, building, testing, packaging, and schema generation. The core library (`pgrx`) offers safe Rust wrappers for PostgreSQL internals: memory contexts, SPI (Server Programming Interface), arrays, triggers, aggregates, GUCs, datetime types, and more. Procedural macros (`#[pg_extern]`, `#[pg_trigger]`, `#[pg_aggregate]`, `#[derive(PostgresType)]`, etc.) automatically generate SQL DDL and Rust boilerplate, enabling a pure-Rust extension development experience. The framework supports PostgreSQL versions 13 through 19 via feature-gated FFI bindings in `pgrx-pg-sys`, which uses `bindgen` to produce per-version Rust declarations. SQL schema generation is handled at compile time by `pgrx-sql-entity-graph`, which embeds metadata in the shared library's binary sections. The architecture is modular: the `pgrx` crate re-exports public API, `pgrx-macros` provides proc macros, `pgrx-pg-sys` contains raw FFI bindings, `pgrx-sql-entity-graph` handles SQL generation, and `cargo-pgrx` is the CLI frontend. Example extensions in `pgrx-examples/` demonstrate features like custom types, background workers, logical decoding, and SPI usage. A comprehensive test suite in `pgrx-unit-tests/` includes compile-fail tests, property-based tests (via `proptest`), and integration tests that run against real PostgreSQL instances. Key external dependencies include the PostgreSQL development headers (for `pg_config` and C API), `libclang` for bindgen, and Rust ecosystem crates such as `serde`, `syn`, `quote`, `clap`, `ureq`, and `criterion` (for benchmarking). The framework is designed for extension authors; it is not a data analysis or research project.
node-gtfs is a comprehensive Node.js library and CLI toolkit for ingesting, querying, exporting, and updating GTFS (General Transit Feed Specification) transit data. It supports SQLite natively and PostgreSQL/MySQL through Kysely, handling static schedule feeds, GTFS Realtime (alerts, trip updates, vehicle positions), and extended standards (GTFS-Plus, GTFS-Ride, GTFS-to-HTML, TODS, TIDES, NOPTIS). The architecture centers on a declarative schema definition system that compiles to SQL table metadata, enabling robust import/export pipelines and a rich query API with ~50 getter functions. The codebase demonstrates strong engineering practices: parameterized SQL builders, structured error handling, configurable reporting, and comprehensive test coverage. It is actively maintained, uses modern tooling (pnpm, TypeScript, ESM), and provides a reusable foundation for transit data applications.
Sqlvet is a static analysis CLI tool for Go projects that scans raw SQL queries embedded in Go source code to detect potential runtime errors at build time. It uses Go's SSA (Static Single Assignment) representation and call graph analysis to trace SQL query strings through function calls, handling common patterns like string concatenation, functions returning query strings, and pass-through functions like sqlx.Rebind. Extracted queries are parsed with a PostgreSQL grammar (via pg_query_go) to validate syntax, table/column names against a schema, and detect unsafe dynamic SQL that could lead to injection. The tool supports custom SQL function matchers via TOML configuration, allowing users to extend analysis to their own wrapper libraries. The architecture is a single Go binary with modular packages for configuration, schema parsing, query extraction, and SQL validation, with comprehensive test coverage including integration tests using real Go packages.
NocoDB is an open-source no-code database platform that provides a spreadsheet-like interface for managing relational databases. It supports multiple view types (grid, form, calendar, kanban, gallery, map, timeline, gantt), rich field types (formula, rollup, lookup, links, attachments, AI prompt), and automations via webhooks and scripts. The architecture is a full-stack monorepo: a NestJS backend with REST APIs (v1–v3), a Vue 3/Nuxt frontend with a custom canvas-based grid renderer, and a shared SDK (`nocodb-sdk`) for types, column helpers, and API client. Key entry points include the server bootstrap (`Noco.ts`), the Nuxt app, and the SDK. Data flows involve Knex-based query building with dialect-specific field handlers, caching via Redis, real-time updates via Socket.io, and background job processing via Bull. External dependencies include PostgreSQL, MySQL, SQLite, MSSQL, Oracle, Redis, and various storage/notification plugins. The codebase demonstrates high craftsmanship with reusable patterns such as column helpers, field handlers, builder generators, caching abstractions, and composables, though it contains many CE stubs for enterprise features and a large migration history.
This is Prisma 8, a next-generation ORM framework written in TypeScript. It provides a contract-driven schema definition system where a 'contract' (JSON + TypeScript types) defines the data model, codecs, extensions, and capabilities. From this contract, the framework generates migrations, a type-safe query builder, and runtime execution for multiple database targets (PostgreSQL, SQLite, MongoDB). The architecture follows a multi-plane design with clear separation between the control plane (schema definition, migration planning, CLI) and the runtime plane (query execution, codec encoding/decoding). The monorepo is organized into layers: foundation (contract IR, canonicalization), core (config, framework components), authoring (PSL parser, contract builder), tooling (CLI, emitter, migration tools), family-specific packages (SQL family, Mongo family), target adapters (Postgres, SQLite, Mongo), and extensions (pgvector, postgis, supabase, etc.). Key entry points include the CLI (packages/1-framework/3-tooling/cli/src/bin.ts), contract definition via defineContract, migration base class, runtime creation (createPostgresRuntime, createMongoRuntime), and the ORM client (Collection). Data flows from contract source (PSL or TypeScript) to contract IR, emission (contract.json + contract.d.ts), migration planning, DDL execution, runtime query building, codec encoding/decoding, and database execution. External dependencies include PostgreSQL (via pg driver), SQLite (via better-sqlite3 or WASM), MongoDB (via mongodb driver), various extensions (pgvector, postgis, etc.), and Node.js/Bun runtimes.
solidtime is an open-source time tracking application designed for freelancers and agencies. It provides a full-stack solution with a PHP backend (using a custom Laravel-like framework with strict typing) and a Vue 3 frontend served via Inertia.js. The system supports multi-tenant organizations with role-based permissions (Owner, Admin, Employee, Placeholder), project and task management, client and tag tracking, billable rates, goals, and detailed reporting with export to CSV, PDF, ODS, and XLSX. It also includes importers for Toggl, Clockify, Harvest, and generic CSV formats, as well as a native solidtime format. The architecture is a monolith with a RESTful API (versioned under /api/v1) and web controllers driven by Inertia.js. The backend uses a custom PHP framework that resembles Laravel but employs non-standard syntax (declare strict_types, use traits, fn closures). Key entry points include API controllers for time entries, projects, clients, tags, goals, reports, and import/export; console commands for administrative tasks, telemetry, and database consistency checks; and a Filament admin panel for CRUD operations. The frontend is built with Vue 3, Pinia stores, TanStack Query for caching, and a shared UI component library (packages/ui) that provides reusable primitives like dialogs, selects, calendars, and context menus. Data flows center around time entries, which are created via a timer or manual entry, associated with projects, tasks, clients, and tags, and aggregated for reporting and goal tracking. The system uses PostgreSQL as its primary database, with Redis for caching and queueing. External dependencies include a mail driver (Mailpit in dev), storage drivers (local/S3), and optional services like Gotenberg for PDF rendering and Paddle for subscriptions. The codebase is extensively tested with PHPUnit (unit/feature), Vitest (JS unit), and Playwright (E2E), and includes CI/CD pipelines for building, linting, and testing.
CS Demo Manager is a mature Electron + React desktop application for managing Counter-Strike 2 and CS:GO demo files. It provides a complete pipeline: downloading demos from Valve, Faceit, 5EPlay, and Renown; parsing them to extract all game events (kills, rounds, economy, grenades, positions, etc.) into a PostgreSQL database; viewing 2D match replays with heatmaps and timeline; generating highlight videos via HLAE/FFmpeg; and exporting statistics to XLSX/JSON. The architecture consists of three processes: an Electron main process for window lifecycle, a React renderer for the UI, and a background Node.js server daemon for demo analysis, video encoding, and scheduled tasks. The codebase is well-structured with strong separation of concerns, extensive type usage, custom error hierarchies, and a comprehensive test suite for core logic. It demonstrates high craftsmanship in generic UI components (virtualized table, heatmap, dialogs) and IPC patterns (typed WebSocket client with reply queue).
This repository implements a comprehensive Telegram bot for managing VPN subscriptions via Remnawave panel integration, featuring a web-based admin cabinet (cabinet) and public API (webapi). The system handles user subscriptions, payments (20+ gateways), referrals, promotional systems, contests, news, and support tickets. Architected with modular layers: Telegram bot handlers (aiogram), cabinet/web API routes (FastAPI), service-layer business logic, and SQLAlchemy ORM with Alembic migrations. Key entry points include main.py (application bootstrap), bot.py (Telegram setup), and unified_app.py (combined web server). Data flows involve Telegram interactions → handler processing → service execution → database CRUD operations, with webhook handlers for payment gateway callbacks and panel synchronization. External dependencies include Telegram Bot API, Remnawave API, PostgreSQL, Redis, SMTP, and numerous payment processors (Yookassa, CryptoBot, etc.). The codebase demonstrates strong engineering practices: clean separation of concerns, dependency injection, structured logging (structlog), and reusable patterns like event emitters, caching utilities, and retry queues. Payment processing abstraction shows particular skill with uniform CRUD interfaces across gateways. Active maintenance is evident through frequent releases, Dependabot integration, and responsive issue triage. While complexity arises from extensive feature set and payment integrations, the modular design contains coupling effectively. Technical drift is low due to current Python version (3.13), updated dependencies, and proactive schema migrations.
pg_bulkload is a high-performance bulk data loading tool for PostgreSQL designed to bypass shared buffers for faster loads. It provides a command-line utility and PostgreSQL extension supporting multiple input formats (CSV, binary, SQL functions), parallel processing, configurable error handling, and crash recovery. The architecture follows a modular pipeline: reader → parser → checker → tuple former → writer, with deep integration into PostgreSQL internals for memory management, error reporting, and index building. Key features include direct path writing (bypassing WAL), multi-process loading via shared memory IPC, and B-tree index construction from sorted data.
pgflow is a PostgreSQL/Supabase-native workflow orchestration engine for defining and executing typed DAGs as background jobs. The system is split into six coordinated packages: a PL/pgSQL core (pkgs/core) that implements the complete workflow state machine in the database — flows, steps, runs, step states, tasks, retries with exponential backoff, map/reduce fan-out, conditional step execution, skip-cascade propagation, and realtime event broadcasting — plus a type-safe TypeScript DSL (pkgs/dsl) for declaring flows with compile-time-enforced inputs/outputs, a Deno/edge worker runtime (pkgs/edge-worker) that consumes PGMQ messages and executes step handlers via platform adapters (Supabase vs. plain process), a realtime-subscription client library (pkgs/client), and a CLI (pkgs/cli) for scaffolding new Supabase projects. Execution relies on pgmq for task queues, pg_cron for stalled-task recovery and worker health, pg_net for HTTP worker invocation, supabase_vault for credentials, and Supabase Realtime for atomic state-transition broadcasts.