Arkitekturen i moderna datasystem genomgår en grundläggande förändring. Fråga en utvecklare hur de bygger datasystem idag, och svaret ser alltmer ut så här: Postgres för applikationen, en sjöhus för analys och datavetenskap. Postgres, länge föredraget för transaktionsarbetsbelastningar, har utvecklats till en operativ databas för allmänt ändamål. Det är pålitligt, flexibelt och djupt utbyggbart, som driver allt från kundtransaktioner och CRUD-appar, till realtids instrumentpaneler och AI-stödda produktfunktioner. Dess ekosystem har vuxit för att stödja realtidsanalys ( Geospatial data (PostGIS), vektor och fulltext sökning (pgvector och pgvectorscale), och mer. TimescaleDB Samtidigt har ökningen av öppna sjöbyggnadstekniker omdefinierat hur organisationer hanterar och analyserar data i stor skala. Disaggregerad lagring, öppna tabellformat som Iceberg, strukturerade datakataloger och komposterbara frågemaskiner har gjort det möjligt att analysera petabyte-skala data med precision och kontroll. Det som är slående är inte bara framgången för dessa tekniker individuellt, utan hur ofta de nu distribueras tillsammans.Organisationer behöver alltmer stödja både operativa arbetsbelastningar (drivna av databaser) och icke-operativa arbetsbelastningar (drivna av sjöhus), ofta med hjälp av data från samma källor – människor, maskiner, digitala system eller agenter. Faktum är att vi tror att en ny, mer sammanhängande arkitektur dyker upp: en som behandlar Postgres och sjöhuset inte som separata världar utan som separata lager av ett enda, modulärt system, utformat för att tillgodose hela spektrumet av operativa och analytiska behov. Gränserna för OLTP vs OLAP Dichotomy Det gamla sättet att tänka på databaser var enkelt: OLTP för transaktioner, OLAP för analys. Du använde Postgres för att driva din app och skickade nattliga ETL-jobb till ett datalager för interna rapporter och instrumentpaneler. Denna traditionella skillnad tjänade oss bra när applikationer var enklare, och intern rapportering kunde leva på en mycket långsammare takt. Moderna applikationer är data-tunga, kundvänliga och realtid genom design.De suddar ut gränserna mellan transaktionell och analytisk. 
 
 
 
 En finansiell app kan köra en handelsmotor som behöver millisekund tillgång till kundportföljer, samtidigt som den levererar riskrapporter i realtid och interna instrumentpaneler. En SaaS-app lagrar inte bara klick – den beräknar användningsmetoder, utlöser varningar och levererar personliga modeller. Ett industriellt övervakningssystem kan ta in tiotals miljoner sensorläsningar per timme, driva anomalidetektering och varningslogik och arkivera år av telemetri för långsiktig analys och AI-modellträning. Dessa användningsfall är inte outliers – de blir snabbt normen. We increasingly see a more useful split: operational databases that power products, and lakehouses that power organizations. Men även om ägandet av dessa typer av system är uppdelat – produkttekniska team som ansvarar för de operativsystem som driver deras produkter, och data team som ansvarar för att hantera sjöhussystem som organisatoriska tjänster – de två behöver fortfarande prata med varandra. En operativ medaljonarkitektur Ett mönster som vi ser få dragkraft är vad vi kallar en Inspirerat av de medaljongmodeller som populariserats i datateknikens värld, innehåller detta mönster också brons-, silver- och guldskikt - inte bara för intern analys, utan också för att driva realtid, användarvänliga system. Operativ medaljarkitektur Här är hur det ser ut: 
 
 
 
 Bronsskikt: Rå data lever i Parquet- eller Iceberg-filer på AWS S3 eller liknande kostnadseffektiva bottenlösa lagringssystem. Dessa data är vanligtvis oföränderliga, endast bifogade och sökbara av något: frågor som AWS Athena, DuckDB, Trino, ClickHouse eller Polars, eller till och med direkt från en operativ databas som Postgres. Operativ Silver Layer: Rengjorda, filtrerade, validerade och deduplicerade data skrivs in i Postgres för att driva realtidsanalys, instrumentpaneler eller applikationslogik av användarvänliga produkter. Operational Gold Layer: Pre-aggregerade data över silverdata (som Postgres materialiserade vyer eller TimescaleDB: s kontinuerliga aggregater) tjänar låg latency, högkonkurrerande produktupplevelser. Viktigt är att varje lager är sökbart, och denna rörelse av data är tvåvägs. Du kan dra råa eller omvandlade data från S3 direkt till Postgres (liknar tätt integrerad omvänd ETL). Du kan rulla upp aggregater från Iceberg till Postgres tabeller (genom enstaka eller stående frågor mot Iceberg-filer från Postgres). Du kan kontinuerligt synkronisera ett fullständigt schema eller en enda tabell från databasen till sjöhuset. Much as bronze (or transformed) data can be read from the lakehouse storage layer on S3 into the database, silver and gold in the database can be written to these lakehouse storage formats. This avoids needing to re-implement identical pipelines in both systems, which both adds complexity and risks consistency. Ett vanligt mönster som vi har observerat i applikationer som kräver färska data är att skriva från ett uppströmssystem som Kafka eller Kinesis. till både S3 (för rad, oförändrade bronsdata) och Postgres (beroende på databasscheman och begränsningar för datavalidering). Sedan exporteras dessa silvertabeller och efterföljande guldaggregat i databasen ut till S3 igen, så att datateam nu har tillgång till de "jordiska sanningsdata" som hade serverats till kunder. I parallell Den operativa databasen kan köras låst – både för användare och ovänliga frågor – medan data fortfarande görs tillgängliga som en del av det öppna sjöhuset där det behövs i org. Varför nu? tekniska krafter som driver förändringen Flera utvecklingar driver detta skifte från de operativa databaserna och sjöhusen från att vara siloade till integrerade. För det första har Iceberg mognat till ett stabilt och flexibelt tabellformat som stöder schemautveckling, ACID-transaktioner och effektiv komprimering. Det gör det möjligt för flera beräkningsmotorer att läsa från och skriva till samma datamängd - med katalogskikt som spårar metadata och genomför styrning över stacken. För det andra har Postgres fortsatt att utvecklas som en plattform. Med tillägg för kolumnarlagring, tidsseriedata och vektor- och hybridsökning – vad vi har byggt på Timescale i åratal – erbjuder Postgres nu många produkter som integrerar realtidsanalys och agentiska arbetsflöden direkt. Och med framväxande stöd för frågande av S3- och Iceberg-data direkt från Postgres blir det alltmer möjligt att integrera S3-hostade data direkt. Detta är inte bara ett data caching lager för förberäknade data, men en fullfjädrad SQL-databas för ytterligare aggregeringar, berikning eller JOINs vid frågetid. now acts as the serving layer for products incorporating both transactional and analytical data För det tredje förväntar sig utvecklare komposibilitet. Vissa organisationer kan vara fast med sina arvade monolitiska dataplattformar, men de flesta utvecklare och datavetenskapare vill ha flexibilitet att komponera sina egna stackar, integrera välbekanta verktyg på sätt som återspeglar deras applikationsbehov. Put differently: the market is moving toward modular, open, developer-friendly architectures. Vad kommer nästa Vi tror att framtiden för datainfrastrukturen kommer att formas av system som integrerar operativa och analytiska lager djupare – system som behandlar Postgres och sjöhuset som två sidor av samma mynt. Det kommer från noggranna gränssnitt – incrementell synkronisering, delade kataloger, enhetliga frågeytor – och från en arkitektonisk filosofi som omfamnar heterogenitet snarare än att bekämpa den. Något som bygger på styrkorna hos Postgres och Iceberg, integrerar tätt med befintliga sjöhussystem och gör det dramatiskt lättare att bygga fullstackade datasystem med operativ och analytisk trohet. Det handlar inte om att använda ETL för att flytta data från gamla system till nya system – det handlar om att bygga en sammanhängande modern dataarkitektur som tjänar både operativa och icke-operativa användningsfall. Håll dig tunad.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Det här ljudet är producerat på berättelsens originalspråk!

För länge; Att läsa

Make resilience your competitive advantage

Postgres och Lakehouse blir ett system - här är vad som kommer nästa

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps