Small software,
done properly.

If you often filter with WHERE email = ... or join on customer_id, those columns should have an index. Without one, the database reads every row. Don't index everything, though: each index slows down inserts and updates a little.

CREATE INDEX ix_orders_customer_id
  ON orders (customer_id);

Concatenating user input into a query opens the door to SQL injection. Always use parameters. It's safer, and the database can reuse the query plan.

// Bad
"SELECT * FROM users WHERE name = '" + name + "'"

// Good
"SELECT * FROM users WHERE name = @name"

SELECT * is handy while exploring, but in real code it pulls more data than needed, breaks when columns change, and can stop the database from using a covering index. List the columns explicitly.

Schedule automatic backups, store a copy somewhere other than the same machine, and restore one to a test database every now and then. That's the only way to know it actually works.

Use proper DATE/DATETIME types instead of text, so sorting and date math just work. For money, use DECIMAL(19,4), never FLOAT, which can't represent amounts like 0.10 exactly.

Moving stock, transferring money, saving an order with its lines: if one step fails, none should apply. Wrap them in a transaction so the data never ends up half-updated.

BEGIN TRANSACTION;
  UPDATE stock SET qty = qty - 1 WHERE id = 7;
  INSERT INTO order_lines (...) VALUES (...);
COMMIT;

Primary keys, foreign keys, NOT NULL, UNIQUE and CHECK constraints catch bad data even when the app has a bug. They're free validation you only write once.