Database
Database
What is a database?
- Stores, retrieves, and manages data systematically
- Where members, orders, and posts are kept
- An app’s memory
What a database really changes is that values don’t break when several people edit at once. With an Excel file, if Manager Park edits it while Associate Kim has it open, one person’s changes overwrite the other’s wholesale. A database either completes a change from start to finish or rolls it back as if it never happened. This prevents the case where a payment went through but no order was recorded, a property developers call a transaction. This is why your numbers stay reliable as the app grows.
Storage comes in two broad types. Relational databases (MySQL, PostgreSQL) fix the table structure and column types in advance and link a member table to an order table by member ID. NoSQL (MongoDB, Firebase) stores data freely in documents, which suits logs and chats whose structure changes often. For internal business apps, starting relational is usually the safer choice. As you scale, what determines speed is not server specs but indexes. Looking up a member by email across 100,000 rows takes seconds without an index, since every row gets scanned, and a few milliseconds with one. It serves a different purpose from an analytics data warehouse: real-time order and login processing belongs in a database, while totaling the past three years of sales belongs in a warehouse.
The two places things break most often in practice are backups and permissions. When you build with vibe coding, the database is created automatically, so people assume “it will be stored somehow.” But it is not rare for a delete command missing one condition to wipe out 8,000 member records at once. Verify for yourself that a daily automatic backup and a recovery test are in place before launch. One more thing: storing passwords or national ID numbers as plain text means instant exposure if they leak, and a violation of the Personal Information Protection Act. A database matters more for how well you protect it than for how you build it.
Jaryong KooMarketing PhD and authority in AI, data analytics, and personal branding
John KimAuthor of B2B Marketing Design and CEO of Nanum ConsultingThe theoretical foundation of relational databases is the relational model that Edgar F. Codd of IBM proposed in 1970. It later became the standard alongside the SQL language.
Let’s look at a hypothetical case. Company A, an industrial safety training provider with 180 employees, had been taking registrations for 700 courses a year through Google Forms and Excel. Once monthly registrations passed 900, duplicate sign-ups and missed cancellations piled up, and three people on the training operations team spent two hours every day reconciling attendee lists. In the first half of 2024, clients even began complaining that certificates of completion took an average of six days to issue.
- Lee, the Training Operations team lead, spread out 12 Excel files, pointed out, "It’s the same person, but the name is written three different ways," and redesigned the structure into three tables: applicants, courses, and enrollment history.
- Working with an outsourced developer, they set up PostgreSQL and added a uniqueness constraint so members are identified by email alone. Over two weeks they migrated 24,000 records from the past three years and filtered out 1,900 duplicates.
- When the sales team’s request, "Pull only those who haven’t completed this month’s electrical safety course," went from 30 minutes of Excel filtering to a 3-second lookup, they started sending re-enrollment emails on the spot.
- The software vendor’s CEO suggested, "Don’t delete canceled orders; just flag them," so records were kept as history instead of being deleted, and automatic backups at 3 a.m. plus a monthly recovery drill were written into the operating rules.
- Six months later, certificate issuance dropped from an average of 6 days to same-day, roster-matching work fell from 2 hours a day to 10 minutes, and duplicate-application inquiries fell from 40 a month to 3.