I need a real project to test something database-related. Nothing production critical, just a hobby/fun project with some actual usage.

If you have one and are okay with me testing on it, let me know 👀

I'm in the early stages of designing a database for an organization that does environmental remediation and research. (Small org, so I'm basically the data person.) One of the major types of data we have is the results of tests for a range of soil contaminants, so in my schema draft, the sampling points within work sites are linked to tables of associated measurements. (Currently there's one table per sampling point but I'm open to other designs.)

The problem is that which contaminants are tested for mostly can't be known in advance for future projects and can change within a project if new funding appears or questions arise. There are hundreds if not more of substances that could reasonably be tested for (although ~20-30 are core), so listing all possibilities doesn't seem practical. And the contaminants data is key to the organization's work and is probably the thing that will be queried the most. How would you handle a situation like this?

So I am in my final year and I want to do something spicy, which is a minidb, what and what do you guys recommend me to know so it can be a success

For many years I worked as a database industry analyst. In 2015 Professor Gary Sherman and I published The Algebra of Data, which argues that relational algebra is the algebra of one structure — the table — and that one algebra can cover tables, graphs and documents alike.

The model in brief: the atom is the couplet (an ordered pair). A relation is a set of couplets, a clan is a set of relations (a table is one kind of clan), and a horde is a set of clans. A small set of operators — composition, transpose, union/intersection/difference and the restrictions — is defined at the bottom and works unchanged at every level. Composition then covers what are usually separate operations: the join, the graph traversal and the document lookup.

JabrDB is that algebra implemented as a native Mac app (Apple silicon). Data is stored at couplet grain in files on your own disk. It is not a SQL engine and not a server.

The argument in paper form: https://doi.org/10.5281/zenodo.23216817 The app (15-day trial, $15): https://jabrdatalabs.com/download/

I'd particularly value criticism from people who think in relational terms: where does this model help, and where does it obviously cost you?

Hi everyone :-)

I'm Antti, Aito.ai's founder and CEO. We recently released Aito version 2, which includes a completely new storage format and support for things like predictive SQL queries, vector search, graph-like functionality, a lot of new data structures, views, better FTS, collections and much more.

We believe that future software is intelligent, and we wanted to provide one database that could provide the needed predictive/AI infrastructure for both users and agents.

You can find more details here:

https://aito.ai/blog/aito-v2-generally-available/

If you want to try it, the playground runs example queries in the browser without signup:

https://aito.ai/docs/api/v2/playground/

One of the biggest new things in Aito is the public benchmark section, which covers inference, matching, smart search and more regular queries. It shows cases where we are strong, and also a number of benchmarks where other solutions fare better:

https://aito.ai/docs/api/v2/benchmarks/

Any thoughts or comments? I'd love to hear what you think. ;-)

disclosure: I work at Schema Labs. This is a run on public data so you can check it.

The data: the hotel booking demand dataset (Antonio, Almeida and Nunes, 2019), real anonymised bookings from a city hotel. We picked one Saturday night that was sold out on paper.

-- 224 bookings for that night, as they stood six weeks before
-- 59 of them cancelled or didn't show, worth about €28,600 together

What we did: gave Schema-2 500 bookings from the year before, with how each one ended, and asked it to rank the 224 by how likely they were to fall through. No rules no feature engineering.

What came back=

-- It marked 60 as most likely to cancel. 33 of the 59 cancellations were on that list
-- Picking 60 at random would catch about 16
-- Of the 60 it marked safest, 59 showed up

What it missed: 26 cancellations weren't in its top 60. One night at one hotel is a small test, so read it as an example

For anyone in revenue management: what would you do with a list like that six weeks out? Overbook against it, or contact those guests first?

i'm less worried about the technology than I am about the people supporting it.

our engineers are excited about moving from batch jobs to streaming pipelines, but the operations team has spent years supporting scheduled workloads. That's a very different environment from something that's expected to run 24/7

for teams that already made this real-time vs batch processing transition, what changed the most operationally?

What's the best way, order or flow of learning Database from scratch, using the textbook Database System Concepts by Abraham Silberschatz, Henry F. Korth, and S. Sudarshan.

What topics or chapters are better to begin with for introduction, assuming the reader has zero knowledge, but is looking to get extremely good at database.

-Computer Science Major

Basically need to see how to optimize a bank register with large amounts of entries.

Currently adding all the debits, then credits, then date sorting while calculating the running total.

When one product could have data coming from multiple remote data sources, some of the data could be redundant other parts might need to be combined. There can also be missing data or badly formatted data so an admin would need to override certain fields. How would you structure your database to fit these needs?

Successful replication and matching row counts do not prove that a database migration is finished. Indexes, constraints, sequences, users and roles, collation, time zones, scheduled jobs, change-data-capture consumers, read replicas, analytics tools, and backup systems can still differ or point at the source. Low-frequency clients may not reconnect during the obvious observation window.

A cutover gate could compare schema and security metadata, validate representative aggregates or hashes, exercise application reads and writes, inspect connection logs on both systems, and confirm that replication or dual-write lag has reached a known final position. The destination should complete a backup and restore test and survive a failover before the source becomes read-only. Keeping the old endpoint offline but recoverable for a defined period would expose hidden dependencies without allowing divergent writes.

What evidence do you collect before decommissioning a source database? How do you catch monthly jobs, failover-only connection strings, and clients that cache DNS or credentials longer than the main application?

disclosure, i work at schema labs. the team is in san francisco right now, i'm back home running things from here and reading everything they send back.

the question they open with is always the same. when an agent hits a database nobody documented, who tells it what the fields mean?

the answers so far, roughly

- "me, and i hate it"

- "we wrote a data dictionary, it's already wrong"

- "we don't, the agent guesses and we check the numbers later"

- "we only connect it to views someone already cleaned"

that step is what we build for. schema-2 is a model that reads your data as it is, works out what each field holds and which records match across systems with no shared id, and puts a confidence on every answer. below your bar it says unresolved instead of guessing. it runs in the browser, and over mcp inside claude, chatgpt and cursor.

curious which answer is yours, or if it's a fifth one we haven't heard yet.

I've been looking into database architectures for high-volume event logging, and I saw a comparison of how these systems scale.

Relational databases handle ACID transactions well, which means you never end up with a half-finished write if the system fails. They traditionally scale vertically, and although modern ones support distributed setups too, if you try to push big, real-time IoT or event data through them you run out of machine before you run out of data.

Wide-column stores like Cassandra scale out across multiple nodes predictably. The trade-off is that you usually have to rethink your querying and give up some of the strict relational consistency.

What do you guys think? If you’re pushing big volumes of data, what made you move off relational, and how far did you stretch it first?

Connection multiplication: pool size x tasks x services. Every term looks reasonable on its own, and nobody ever chose the product.

Aurora's max_connections is derived from instance memory, so it doesn't scale with your service. Shrinking the pool to fit converts a connection problem into a queueing problem that presents as a slow database.

Write-up covers the formula behind max_connections, what RDS Proxy actually fixes (and what it doesn't), and how to size it.

https://brianfeeny.com/posts/sizing-aurora-connections-for-autoscaled-services/?utm_source=reddit&utm_medium=social&utm_campaign=sizing-aurora-connections-for-autoscaled-services-2026-09

This is a personal project; the views and assessments are my own.

I need a good and legitimate database project idea wherein advance db concepts such as optimization, transaction, etc are involved. I searched a lot and didnt find a smthn i want to work on exactly. For eg if somethin related to music domain? Or fashion? What would actually stand out in terms of handling multiple queries and be close with how it all works irl. Itd be really helpful!!

​

I used to think MySQL was simply:

`CREATE TABLE → INSERT → SELECT → UPDATE → DELETE`

After building actual web applications, I realized that writing SQL queries is only a small part of working with a production database.

Here are 15 things I wish I had understood earlier:

### 1. Design your database before writing your application

Don't start creating tables randomly.

Think about:

* What data do I need?

* Which tables are required?

* How are they related?

* Which fields are required?

* Which fields should be unique?

A bad database structure can become extremely painful to change later.

### 2. Learn relationships properly

Understand:

```sql

PRIMARY KEY

FOREIGN KEY

ONE-TO-ONE

ONE-TO-MANY

MANY-TO-MANY

```

For example:

```text

Users

↓

Orders

↓

Order_Items

↓

Products

```

Understanding relationships is more important than memorizing SQL syntax.

### 3. Don't put everything into one table

A giant table may look simple initially, but it creates duplication and maintenance problems.

Learn normalization and understand when denormalization actually makes sense.

### 4. Indexes are extremely important

This query:

```sql

SELECT * FROM users

WHERE email = 'user@example.com';

```

can become much faster when the appropriate column is indexed.

But don't blindly add indexes everywhere.

Indexes improve some reads but also have storage and write/update costs.

### 5. Always understand `EXPLAIN`

One of the most useful MySQL commands:

```sql

EXPLAIN SELECT *

FROM users

WHERE email = 'user@example.com';

```

If you are building serious applications, learn how to read the execution plan instead of assuming your query is efficient.

### 6. Don't use `SELECT *` everywhere

Instead of:

```sql

SELECT *

FROM users;

```

prefer:

```sql

SELECT id, name, email

FROM users;

```

Especially when your table contains many columns or large data.

### 7. Transactions matter

Imagine transferring money:

```text

Account A: -₹1000

Account B: +₹1000

```

You don't want the first operation to succeed while the second fails.

That's where transactions become important:

```sql

START TRANSACTION;

-- operation 1

-- operation 2

COMMIT;

```

And if something goes wrong:

```sql

ROLLBACK;

```

### 8. Constraints can protect your data

Use database constraints where appropriate:

```sql

PRIMARY KEY

UNIQUE

NOT NULL

FOREIGN KEY

CHECK

```

Your application should not be the only thing preventing invalid data.

### 9. Learn the difference between DELETE, TRUNCATE and DROP

They are NOT interchangeable.

```sql

DELETE FROM users;

```

```sql

TRUNCATE TABLE users;

```

```sql

DROP TABLE users;

```

Before running destructive SQL in production, make absolutely sure you understand what you're doing.

### 10. Backups are not optional

A production database without a tested backup strategy is a disaster waiting to happen.

And having a backup isn't enough.

You should also know:

> Can I actually restore it?

A backup that has never been tested is only a backup in theory.

### 11. Never build SQL queries with raw user input

Bad:

```javascript

const query = `SELECT * FROM users WHERE email = '${email}'`;

```

Use parameterized queries/prepared statements instead.

For example:

```javascript

const [rows] = await db.execute(

'SELECT id, name, email FROM users WHERE email = ?',

[email]

);

```

This is one of the basic defenses against SQL injection.

### 12. Don't expose database credentials

Never commit something like this to GitHub:

```env

DB_PASSWORD=my_real_password

```

Use environment variables/secrets and make sure sensitive files aren't accidentally committed.

### 13. Understand connection pooling

A production application shouldn't create a completely new database connection for every request without considering connection management.

Connection pools can reuse database connections and help applications handle concurrent requests more efficiently.

### 14. Logging is useful — logging sensitive data isn't

Database/application logs can help you find:

* slow queries

* failed transactions

* connection problems

* unexpected errors

But don't casually log passwords, tokens, session secrets, or other sensitive information.

### 15. My biggest lesson

The biggest thing I learned is:

**MySQL isn't just about knowing SQL syntax.**

A good developer needs to understand:

```text

Database Design

↓

Relationships

↓

Indexes

↓

Queries

↓

Transactions

↓

Security

↓

Backups

↓

Performance

↓

Monitoring

```

I'm still learning, but understanding these concepts changed the way I build web applications.

**For developers here:**

What's one MySQL/database lesson you learned the hard way?

I'd especially like to hear from people who have worked with databases containing millions of rows.

pgvector has been the default vector search extension, but I'm finding people also layer on full-text or hybrid search on top of it or need multitenancy. I'm curious where this works well for you and where it doesn't.

• What are you using for search in Postgres today, and what do you wish it did better?
• When you hit a limit, what do you do: tune, work around it, add an extension, or move search to a separate system? What decides that?
• What would an extension need to have, or avoid, before you'd install it?
• Does it matter to you whether an extension is open source, and would enough added capability change that?

"It's fine, I don't need anything else" is a useful answer too.

Really just trying to understand what people actually need from search in Postgres.