Folgen

  • Why Database Snapshot Isolation Breaks at Write Skew

    Why Database Snapshot Isolation Breaks at Write Skew
    Jul 17 2026
    Episode 116 of Database Tech with Fexingo. Lucas and Luna dive into write skew, a subtle concurrency anomaly that breaks snapshot isolation even when individual transactions are consistent. Using the classic doctor-on-call scheduling example, they explain how PostgreSQL's default snapshot isolation can allow two overlapping transactions to violate a business rule without ever reading each other's data. They contrast this with serializable isolation, which uses predicate locks and serialization anomalies to catch write skew, and discuss real-world tradeoffs: performance cost versus correctness. If you've ever assumed MVCC means no conflicts, this episode will change your mind. Perfect for engineers using PostgreSQL, MySQL (with InnoDB), or any database relying on snapshot isolation. Includes concrete steps to test for write skew and when to escalate isolation levels. #WriteSkew #SnapshotIsolation #PostgreSQL #MVCC #ConcurrencyControl #DatabaseAnomalies #SerializableIsolation #PredicateLocks #DoctorOnCall #BusinessLogic #TransactionIsolation #SQL #NoSQL #DatabasePerformance #FexingoBusiness #TechnologyPodcast #DatabaseEngineering #Episode116 Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    8 Min.
  • Why Database Multi-Tenancy Needs Tenant Isolation Not Shared Tables

    Why Database Multi-Tenancy Needs Tenant Isolation Not Shared Tables
    Jul 16 2026
    Episode 115 of Database Tech with Fexingo. Lucas and Luna drill into multi-tenant database design, using a real SaaS case: a mid-market CRM that hit a noisy-neighbor crisis when one tenant's bulk import saturated disk I/O for everyone. They contrast shared-table vs. schema-per-tenant vs. database-per-tenant architectures, explain why connection pooling and query plan caching break across tenants, and walk through the trade-offs of row-level security policies vs. dedicated pools. The episode lands on a hybrid pattern: tenant-aware routing with per-tenant connection pools and a shared metadata store. Listeners get a concrete decision framework for choosing isolation levels without over-engineering. Plus: why the ad-free model matters to a show that treats listeners like engineers, not audiences. #MultiTenancy #DatabaseArchitecture #TenantIsolation #SaaS #PostgreSQL #RowLevelSecurity #ConnectionPooling #NoisyNeighbor #SchemaPerTenant #DatabasePerTenant #SharedTable #Technology #FexingoBusiness #BusinessPodcast #DataEngineering #DatabasePerformance #CRMSystem #QueryPlanCaching Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    10 Min.
  • Why Database Row-Level Security Hurts Query Performance

    Why Database Row-Level Security Hurts Query Performance
    Jul 16 2026
    Row-level security (RLS) is a powerful feature for multi-tenant databases, but it comes with a hidden cost: query performance can degrade significantly if not implemented carefully. In this episode, Lucas and Luna explore how RLS policies interact with query planners, indexing strategies, and connection pooling, using a real-world example of a SaaS platform that saw query latency spike by 300% after enabling RLS. They discuss why predicate pushdown fails, how to design policies that leverage partial indexes, and when to move security logic to the application layer instead. For any engineer dealing with multi-tenant architectures, this is a must-listen on balancing security with speed. #RowLevelSecurity #QueryPerformance #DatabaseSecurity #MultiTenant #PostgreSQL #PredicatePushdown #PartialIndex #QueryPlanner #ConnectionPooling #SaaS #DatabaseOptimization #TechPodcast #Technology #FexingoBusiness #BusinessPodcast #DatabaseDesign #SecurityVsPerformance #DataEngineering Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    5 Min.
  • Why Database Storage Engines Need Log-Structured Merge Trees

    Why Database Storage Engines Need Log-Structured Merge Trees
    Jul 15 2026
    In this episode of Database Tech with Fexingo, Lucas and Luna dive into log-structured merge trees (LSM trees) and why they underpin modern write-heavy databases like Cassandra, LevelDB, and RocksDB. They unpack the trade-offs between LSM trees and traditional B-trees, focusing on write amplification, compaction strategies, and real-world performance implications. Using a concrete example of a time-series metrics system ingesting one million data points per second, they explain how LSM trees turn random inserts into sequential writes and why that matters at scale. Lucas breaks down the compaction process — level-based vs. size-tiered — and Luna questions when LSM trees might actually hurt you. The episode also touches on how compactions cause read stalls and space amplification, and why some databases now mix B-tree and LSM approaches. Perfect for engineers tuning storage backends or choosing a database for high-ingestion workloads. #LSMTrees #DatabaseEngines #StorageEngines #WriteAmplification #Compaction #LevelDB #RocksDB #Cassandra #BTree #TimeSeries #HighThroughput #SequentialWrites #RandomWrites #DatabaseInternals #Technology #DataEngineering #FexingoBusiness #BusinessPodcast Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    6 Min.
  • Why Database Query Plan Caching Backfires at Scale

    Why Database Query Plan Caching Backfires at Scale
    Jul 15 2026
    Episode 112 of Database Tech with Fexingo tackles a hidden performance killer: query plan caching. Lucas and Luna unpack why reusing cached plans can lead to catastrophic suboptimal execution as data distributions shift, using a real-world case from a mid-size e-commerce company that saw query latency spike 10x after a data ingestion update. They explain the difference between simple and parameterized plans, the role of statistics staleness, and why SQL Server's 'parameter sniffing' is both a feature and a footgun. The hosts discuss mitigation strategies like plan forcing, query hints, and adaptive query processing, and why some teams disable caching entirely for volatile workloads. By the end, listeners understand that caching isn't always a performance win — and when to invalidate it deliberately. #QueryPlanCaching #SQL #Performance #Database #ParameterSniffing #PlanCache #SQLServer #PostgreSQL #Statistics #Optimizer #Indexing #ExecutionPlan #Tech #DatabaseTechWithFexingo #FexingoBusiness #BusinessPodcast #SoftwareEngineering #DataEngineering Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    7 Min.
  • Why Database JSON Schema Validation Costs You Performance

    Why Database JSON Schema Validation Costs You Performance
    Jul 14 2026
    In this episode of Database Tech with Fexingo, Lucas and Luna dig into a hidden performance trap in modern databases: JSON schema validation. When you store semi-structured data in columns like PostgreSQL's JSONB or MongoDB, every write triggers a schema check against your defined rules. Lucas breaks down the cost using a real-world example from a logistics company that hit 50-millisecond write latencies after adding a 15-field JSON schema. They discuss why the validation overhead scales with document complexity, not size, and how a simple change—moving validation to the application layer—cut their p99 write latency by 80 percent. Luna pushes back on whether that trade-off is always safe, and they explore where schema validation belongs in your data pipeline. If you're using JSON columns with constraints, this episode will change how you think about write performance. No fluff, just a deep, practical dive into a specific query-engine behavior that most teams discover the hard way. #DatabaseTechWithFexingo #TechPodcast #JSON #SchemaValidation #PostgreSQL #MongoDB #Performance #WriteLatency #DataEngineering #QueryOptimization #NoSQL #SQL #DatabasePerformance #BackendEngineering #SoftwareArchitecture #FexingoBusiness #BusinessPodcast #DataStorage Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    8 Min.
  • Why Database Connection Pool Sizing Needs Dynamic Scaling

    Why Database Connection Pool Sizing Needs Dynamic Scaling
    Jul 14 2026
    In this episode of Database Tech with Fexingo, Lucas and Luna drill into the failure of static connection pool formulas. Using a real-world example from a mid-size e-commerce platform that hit a 503 avalanche during a flash sale, they explain why fixed pool sizes based on max connections or response time are brittle. Lucas introduces the concept of dynamic pool sizing using queue-depth metrics and adaptive scaling, referencing approaches from HikariCP and AWS Aurora. Luna pushes back on overhead concerns, and they walk through a concrete implementation: a pool that monitors active threads vs. queue depth and adjusts min/max connections every 30 seconds. They close with the open question of whether this logic belongs in the application or the database driver. No vague best practices — just one specific failure and one specific fix. #ConnectionPool #DynamicScaling #DatabasePerformance #HikariCP #Aurora #ECommerce #FlashSale #503Errors #QueueDepth #AdaptiveScaling #DatabaseTech #Technology #FexingoBusiness #BusinessPodcast #DatabaseArchitecture #Engineering #ProductionIncidents #Scalability Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    11 Min.
  • Why Database Partition Pruning Fails Without Partition Elimination

    Why Database Partition Pruning Fails Without Partition Elimination
    Jul 13 2026
    Partition pruning is supposed to speed up queries by skipping irrelevant partitions, but it breaks silently when queries don't match the partition function exactly. Lucas and Luna dig into a real case from a logistics company: a 32-terabyte PostgreSQL time-partitioned table where a date-casting mismatch forced full-table scans on every query. They explain how partition elimination happens under the hood, why timestamp vs timestamptz type mismatches kill it, and what a proper partition-aware query plan looks like vs a sequential scan. They also cover how to detect missing partition pruning with EXPLAIN ANALYZE and pg_stats, and why the same problem appears in MySQL, BigQuery, and Snowflake. If you think partition pruning is automatic, this episode will save you a lot of wait time at 2 AM. #PartitionPruning #PartitionElimination #PostgreSQL #DatabasePerformance #QueryOptimization #DataPartitioning #TimeSeriesData #EXPLAINANALYZE #SequentialScan #DatabaseIndexing #BigQuery #Snowflake #MySQL #TypeCasting #QueryPlans #Technology #FexingoBusiness #BusinessPodcast Keep every episode free: buymeacoffee.com/fexingo
    Mehr anzeigen Weniger anzeigen
    9 Min.