Ano ang Postgres? Ang Database sa Likod ng Maraming App, Ipinaliwanag

Ang Postgres (opisyal na PostgreSQL) ay libre at open-source na relational database: programa na nag-iimbak ng datos ng app sa mga table na may row at column, nagdurugtong sa mga table na iyon, at sumasagot sa mga tanong tungkol sa mga ito gamit ang wikang tinatawag na SQL. Kilala ito sa pagiging maaasahan, sa higpit sa pag-iingat ng tamang datos, at sa kakayahang umangkop mula sa listahan ng sign-up hanggang sa malalaking talaan ng kumpanya. Maraming web app, at maraming serbisyong nagho-host sa mga ito, ang nakabatay dito.

Bakit mahalaga ito kapag gumagawa ka gamit ang AI

Kapag nagdagdag ang AI app builder ng “database” sa project mo, malaki ang tsansang Postgres ito. Hindi mo kailangang magsulat ng SQL para magamit ito, pero malaki ang maitutulong ng kaunting pag-unawa:

Puwede mong ilarawan ang datos sa hugis na kailangan ng database. Ang “May maraming order ang bawat customer; bawat order ay may maraming item” ay direktang nagiging mga table.
Puwede kang humiling ng tamang proteksyon. Kayang tanggihan ng Postgres ang maling datos sa sarili nitong paraan — gaya ng dobleng email, o order para sa customer na wala — kung itatakda ng AI ang mga panuntunan.
Puwede mong basahin ang ginawa ng AI. Madaling suriin ang pangalan ng mga table, column, at ugnayan sa table viewer, kahit hindi mo hinahawakan ang code.

Halimbawang madaling maintindihan: isang napakahigpit na tanggapan ng mga file

Isipin ang isang tanggapan ng mga file na may kabinet para sa bawat uri ng bagay — isa para sa customer, isa para sa order, isa para sa produkto. May parehong nakalimbag na kahon na dapat punan ang bawat card sa drawer. May sariling natatanging numero ang bawat card, at ang order card ay hindi inuulit ang detalye ng customer; sinasabi lang nitong “customer #214,” na nakaturo sa drawer ng customer.

Mahigpit ang klerk. Hindi nila ifa-file ang order na nakaturo sa customer na hindi umiiral. Hindi nila tatanggapin ang card na blangko ang kahon ng petsa kung kailangan ito. At kung ipapalipat mo ang pera mula sa isang account card papunta sa isa pa, alinman sa dalawang kalahati ang gagawin nila o wala — hindi kailanman isa lang.

Ang klerk na iyon ay ang Postgres. Ang mga drawer ay table, ang nakalimbag na kahon ay column, ang bawat card ay row, at ang “customer #214” na link ay isang foreign key.

Ang mahusay gawin ng Postgres

Feature	Ano ang ibig sabihin sa simpleng salita
Mga table at ugnayan	Nakatira ang datos sa mga table na nagtuturo sa isa't isa, kaya walang kinokopya sa limang lugar
SQL	Pamantayang wika para magtanong: “lahat ng hindi pa bayad na order noong nakaraang buwan, pinakabago muna”
Transaction (ACID)	Ang isang grupo ng pagbabago ay alinman sa lahat ang nangyayari o wala, kahit mag-crash ang server sa gitna
Constraint	Mga panuntunang mismong ipinapatupad ng database: kailangang field, natatanging email, wastong link sa pagitan ng mga table
Index	Mga shortcut sa paghahanap para mabilis pa rin ang search habang lumalaki ang mga table
JSONB	Mag-imbak ng flexible, parang-dokumentong datos sa isang column kapag hindi bagay ang nakapirming istruktura
Full-text search	Maghanap ng mga salita sa text field nang walang hiwalay na search service, para sa simpleng kaso
Extension	Mga dagdag gaya ng PostGIS para sa mapa at lokasyon, o pgvector para sa pag-iimbak ng AI embedding
Row-level security	Mga panuntunan sa loob ng database kung aling mga row ang puwedeng makita ng isang user

Nagsimula ang Postgres bilang research project sa University of California, Berkeley, noong dekada 1980, at mula noong dekada 1990 ay binuo ito nang bukas ng pandaigdigang komunidad. Ang mahabang kasaysayang iyon ang dahilan kung bakit madalas itong default na pagpipilian: maayos ang dokumentasyon, malawak ang suporta, at may managed na bersyon ang bawat pangunahing cloud provider.

Halimbawang sitwasyon: pag-convert ng spreadsheet sa mga table

Isipin mong nagpapatakbo ka ng maliit na catering business at sinusubaybayan ang lahat sa iisang spreadsheet: bawat row ay isang event, may pangalan, telepono, at email ng kliyente, petsa, mga item sa menu, at presyo.

Mabilis lumitaw ang mga problema. Ang parehong kliyente ay nasa anim na row na may dalawang magkaibang numero ng telepono. Ang mga item sa menu ay tinype sa iisang cell bilang “canapés x40, salad x2,” kaya hindi mo mabibilang kung ilang canapés ang nagawa mo ngayong buwan.

Sa Postgres, ang parehong impormasyon ay nagiging apat na table:

Table	Mga column	Mga tala
clients	id, name, phone, email	Dapat natatangi ang email
events	id, client_id, date, venue, status	Dapat tumugma ang client_id sa tunay na kliyente
menu_items	id, name, unit_price	Isang row bawat ulam
event_items	event_id, menu_item_id, quantity	Nagdurugtong sa mga event at ulam, kasama ang dami

Ngayon, nasa iisang lugar na ang numero ng telepono ng kliyente. Ang “Ilan ang canapés na nagawa natin noong Marso?” ay isang SQL query lang. At kapag nire-record mo ang bagong event kasama ang mga item nito, sinisiguro ng isang transaction na hindi ka kailanman mauuwi sa event na kalahati lang ang na-save na item.

Ito ang hakbang na nilalaktawan ng mga tao kapag humingi sila sa AI ng “gumawa ng app mula sa spreadsheet ko.” Mas detalyado ang gabay sa pag-convert ng spreadsheet sa app.

Mga pangunahing termino

Table, row, column: isang uri ng bagay, isang halimbawa nito, isang piraso ng impormasyon tungkol dito.
Primary key: ang natatanging ID ng bawat row, karaniwang id.
Foreign key: column na nagtuturo sa row sa ibang table, gaya ng client_id.
Schema: ang disenyo ng lahat ng table at column mo.
Migration: naka-save at paulit-ulit na mailalapat na pagbabago sa schema, gaya ng “magdagdag ng venue column sa events.”
Query: tanong o utos na nakasulat sa SQL.
Connection string: ang address at password na ginagamit ng backend mo para maabot ang database. Secret ito — tingnan ang environment variables at secrets.
Managed Postgres: serbisyong nagpapatakbo, nagba-backup, at nag-a-update ng Postgres para sa iyo.

Para sa mga pangkaraniwang operasyong ginagawa ng bawat app sa mga table na ito — create, read, update, delete — tingnan ang ano ang ibig sabihin ng CRUD.

Mga karaniwang pagkakamali at maling akala

Isang napakalaking table. Ang pagkopya ng column ng spreadsheet nang eksakto ay humahantong sa parehong problema ng pag-uulit. Ihiwalay sa sariling table ang mga bagay na paulit-ulit.
Pag-iimbak ng listahan sa iisang text field. Ang “canapés x40, salad x2” sa iisang column ay hindi mabibilang o mahahanap nang maayos. Gumamit ng linking table.
Walang constraint. Kung walang “dapat natatangi ang email” o “bawat event ay kailangan ng kliyente,” tahimik na papasok ang maling datos at lilitaw pagkalipas ng ilang buwan.
Pagbabago ng database nang mano-mano sa production. Humingi ng mga pagbabago sa schema bilang migration, para maitala ang pagbabago at maulit.
Pagpapahintulot sa browser na direktang kausapin ang database. Dapat dumaan ang frontend sa backend mo, na nagsusuri ng permission. Hindi kailanman dapat nasa page code ang password ng database.
“Para lang sa malalaking kumpanya ang Postgres.” Masaya rin itong tumatakbo para sa waitlist na 50 row, at hindi mo na kailangang lumipat habang lumalaki ka.
Pag-aakalang backup ang database. Nag-iimbak ito ng datos; hindi ito awtomatikong nagpoprotekta sa iyo mula sa pagbura. Suriin kung anong backup ang ibinibigay ng host mo.

Ano ang hihilingin sa AI builder mo

“I-save ang [mga bagay] sa database. Mga table: … na may mga field na ito: … I-link ang bawat [order] sa isang [customer].”
“Gawing natatangi ang email sa customers. Gawing kinakailangan ang mga field na ito. Huwag payagan ang order na walang customer.”
“Gumamit ng migration para sa bawat pagbabago ng schema.”
“Magdagdag ng index para sa mga paghahanap na pinakamadalas nating gawin: order ayon sa customer at ayon sa petsa.”
“Lahat ng access sa database ay dumaraan sa server. Itago ang connection string sa environment variables.”

Kung bago ka pa sa ideya ng database, magsimula sa ano ang database, saka bumalik dito. Ipinapakita ng full-stack app kung saan nakalagay ang database sa tabi ng frontend at backend.

Postgres sa Mythex

Binibigyan ng Mythex ang bawat project na nangangailangan nito ng sarili nitong dedicated na Postgres database. Hindi mo ito kailangang i-configure: humiling sa chat (“I-save ang waitlist emails sa database”) o gamitin ang /database command, at ikakabit ito ng Mythex, ilalagay ang connection details sa app mo, at puwedeng gumawa ng mga table para sa iyo. Natutulog ang database ng naka-publish na app pagkatapos ng limang minutong walang gawain at nagigising sa susunod na request, at sinisingil ka para sa oras na talagang gising ito, mula sa parehong credit balance ng paggawa. Nasa database docs ang mga detalye, at magandang makita ang mga app na may datos sa dashboard templates.

Mga tanong

Pareho ba ang Postgres at PostgreSQL?

Oo. Ang PostgreSQL ang opisyal na pangalan at ang Postgres ang karaniwang maikling pangalan; parehong tumutukoy sa iisang open-source na relational database.

Libre ba ang Postgres?

Oo. Open source ang PostgreSQL sa ilalim ng maluwag na PostgreSQL License, kaya puwede mo itong gamitin nang libre, kasama sa mga komersyal na produkto. Nagbabayad ka lang para sa mga server o managed na serbisyong nagpapatakbo nito.

Ano ang pagkakaiba ng Postgres at MySQL?

Parehong libre at relational SQL database, at parehong mahusay para sa karamihan ng app. Kilala ang Postgres sa mahigpit na integridad ng datos, mayayamang uri ng datos gaya ng JSONB at array, at malaking ecosystem ng extension; kilala naman ang MySQL sa pagiging simple at mahabang kasaysayan sa web hosting.

Mainam ba ang Postgres para sa maliit na app?

Oo. Mahusay itong gumagana para sa isang simpleng waitlist table at para sa malalaking production system, kaya hindi mo kailangang lumipat ng database habang lumalaki ang app. Pinapadali ng mga managed na serbisyo ang pagpapatakbo nito nang walang database administrator.