In 09-01 we looked at slow learning: books, chapters worked through with the keyboard in front of you, one title every three months. This lesson covers the other side, the one that produces results in weeks: official documentation studied seriously, platforms where you write SQL and something corrects you instantly, university courses published openly, and the sources that keep you current once the course is over.

It also covers something almost nobody explains and that saves months: how to tell a course that teaches from one that entertains. There is an enormous amount of database material online, and a good part of it is the same SELECT * FROM customers repeated for nine hours of video. Learning to discard quickly is a skill as valuable as knowing how to choose.

The lesson ends with a concrete twelve-week study plan template, built exactly on the point where this course has left you: someone who has designed and normalized a schema, has written multi-table and aggregate queries, has read an execution plan, has modeled documents in MongoDB and has split a system across four engines.

Important warning. Course availability, prices, free tiers, contents and even existence change constantly. Platforms withdraw courses, universities reorganize their programs, and free tiers are cut back or extended without notice. This lesson quotes no prices and gives no deep links: for each course its exact title and the institution that teaches it are given, and the instruction is that you search for it by that title on the corresponding platform. Before enrolling or paying for anything, check at the official source what is available today.

1. How to choose an online course without wasting your time
2. Official documentation as the first resource
3. How the PostgreSQL manual is studied
4. The documentation of the other engines
5. Interactive practice platforms
6. Structured courses from universities and platforms
7. Blogs, channels and newsletters for keeping current
8. Certifications: who they are for and who they are not
9. Your personal study plan: a 12-week template
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

Before the list, the filter. These are the signals you can check in ten minutes, before investing forty hours.

SQL syntax is small. The essentials fit in a couple of evenings, and this course already gave them to you in module 2. What takes years is the other thing: deciding. Whether that column should allow NULL, whether that table should be split, whether that index is going to be worth anything, whether that JOIN should be a subquery, whether that operation needs a transaction and at what isolation level.

A course that only teaches syntax produces a pleasant sensation of progress — every lesson adds a new keyword — and leaves the student unable to design anything. It is the reason this course devoted two whole modules (4 and 5) to design and normalization before considering the matter finished, and why modules 7 and 8 were all exercises and case studies.

When you evaluate a course, look for the decisions part. If it does not have one, it does not matter how many hours it runs.

Put plainly: in a technical interview, a completion certificate from an open platform counts for very little, and a repository with a well-designed schema, its migrations, its justified indexes and a README explaining the decisions counts for a great deal.

The reason is not snobbery. The certificate proves you saw the material; the project proves you made decisions under constraints and that you can defend them. And decisions are the job.

That is why, in the twelve-week plan of section 9, every block has a deliverable, and the certificate appears nowhere.

The most widespread and most expensive habit is searching the internet before searching the manual. It is done because the manual "is dense" and the forum answer "is faster". That is true in the short term and false in the medium term: the forum answer is from 2013, it was written for another version, it solves a similar case but not yours, and it does not teach you where to look next time.

Always start with the official documentation. And not only for one-off lookups: study it in blocks, as if it were a book, because in several of these engines it is one.

Two warnings about documentation. First: always check the version. The PostgreSQL manual is published per version and it is easy to end up reading the one for a version you do not have installed; check the page's version selector. Second: the official documentation overrides any course, blog or forum answer. If a video says one thing and the manual says another, the manual is right.

The PostgreSQL manual is intimidating because of its size, and it should not be: it is organized into parts with very different purposes, and only two or three are continuous reading. This is a reasonable reading order for someone finishing this course.

A method that works well: one section of the manual per week, with a query notebook of your own. For each section, write five queries against BiblioRed that use something you have just discovered. The data types section, for example, will almost certainly make you rewrite a couple of columns in your schema as soon as you discover range types and timestamptz.

MongoDB Manual and MongoDB University. The manual (https://www.mongodb.com/docs/) has a data modeling section that is required reading after 03-03: it formalizes the embed-versus-reference criterion you applied by feel in 08-02, with its named patterns. Besides the manual, MongoDB maintains MongoDB University, a training platform of its own with learning paths for development and administration, reachable from the official MongoDB site. It is one of the best-made product training programs in existence. Like everything else in this lesson: check on the official site which paths are available today and under what conditions, because they change.

SQLite. Its documentation has an unusual and valuable feature: besides the reference, it publishes opinion and design documents — when to use SQLite and when not to, why its type system is dynamic, which limitations are deliberate. Reading those pages is the best continuation of 01-02, because they explain honestly what an embedded database is for and what it is not. Root: https://sqlite.org/.

Redis. The documentation (https://redis.io/docs/) is organized by data type, and that organization is itself the teaching: understanding what a sorted set solves versus a list versus a hash is understanding Redis. The key expiry part and the persistence part are the ones that ground what you did in 08-03 with VallBici's real-time availability.

Neo4j. Its documentation (https://neo4j.com/docs/) includes learning material for the Cypher language and for graph modeling. Neo4j was the engine mentioned in 03-02 and never practiced; if you want to fill that gap, this is the best place to do it, and graph modeling has an interesting side effect: it forces you to think of relationships as first-class citizens, which changes how you see the relational model.

Elasticsearch. The documentation at https://www.elastic.co/ covers text analysis, mappings and the query language. What is worth studying after 08-03 is the analyzers part: understanding what happens to a piece of text between being indexed and being searched is what explains why Elasticsearch finds "Vallmar" when you type "valmar" and ILIKE does not.

Writing SQL and having something tell you immediately whether it is right is, for learning queries, more effective than any video. These are the established platforms.

That last point deserves emphasis: interactive platforms teach you to query, not to design. They cover module 2 perfectly and much of module 7, and they do not cover modules 4, 5 and 8. There is no shortcut for design: it is learned by designing and by submitting the design to criticism.

Here exact titles and institutions are given. Search for them by that title on the corresponding platform; catalogs and addresses change, which is why no links to specific listings are given.

What it is. Carnegie Mellon publishes openly, term after term, its database systems courses: the recorded lectures, the slides, the project assignments. It is top-tier university material available without enrolling.

What it covers. The introductory course goes through storage, page formats, B-tree indexes, query processing, planning and optimization, concurrency control, recovery and distributed systems. The graduate one goes deep into modern engines, vectorized execution and columnar storage.

Level. High. It is a computer science course, with systems programming in the projects.

How to work through it. Do not attempt the whole thing up front. It is the perfect continuation of 01-04 — where a database engine's architecture was described from the outside — and of 06-03 — where you read execution plans without knowing how they are generated. Start by watching only the lectures on indexes, query processing and query optimization, in that order. If they hook you, carry on; if not, you have already got the main thing.

What to skip. The programming projects, unless you want to build engines for a living. Watching the lectures without doing the projects already gives you a great deal.

What it is. The material from Stanford's classic database course, reorganized into several self-guided mini-courses, each focused on one block. It is probably the most veteran and most polished online database course in existence.

What it covers. The relational model and SQL, design and theory — including functional dependencies and normal forms, with more rigor than module 5 gave — semistructured data (XML, JSON), and advanced SQL topics such as views, triggers and constraints.

Level. Medium, with demanding theoretical parts.

How to work through it. If in 05-02 you were left with the feeling of having applied the normal forms without fully understanding their foundation, the modeling and theory mini-course is exactly the remedy. The exercises are automatically graded, which for theory is rare and very valuable.

What to skip. The XML part, unless you have a specific interest; today it carries much less weight than it did when it was recorded.

Once the course is over, the problem stops being learning and becomes not rusting. The trap here is subscribing to thirty sources, reading none of them and feeling bad about it. The strategy that works is the opposite: two or three fixed sources and a fixed slot each week.

About Jepsen, a note: it is the place where commercial claims about consistency are genuinely put to the test. After 06-02 and 08-03, reading a Jepsen report on an engine you thought you knew is a notably formative experience, because it shows the distance between what a product promises on its website and what it guarantees under a network partition.

How not to drown. Three rules. One: aggregators are read by headline, not by article; you open two, not twelve. Two: if a topic does not touch you at work or in a project of your own, reading about it is entertainment, not training — which is fine, but do not count it as study. Three: reserve a fixed slot, thirty minutes a week, and outside that slot read nothing. Technical news is almost never urgent.

Certifications come in three families: database product ones (for example, MongoDB's official certifications for development and administration, or the ones offered by the companies that give commercial support for PostgreSQL), cloud provider ones (the big three all have data and database certifications, with catalogs they reorganize often) and training platform ones, which are really completion certificates and not certifications.

Two cautions. First: the catalogs, names, codes and requirements of certifications change frequently — exams are withdrawn, renamed, merged; always consult the provider's official catalog and do not trust third-party lists, this one included. Second: the greatest value of a certification is usually not the diploma, but that its official syllabus is an excellent checklist of what you ought to know. You can use that syllabus as a study plan without ever sitting the exam, and that is a perfectly legitimate strategy.

A study plan needs five things: realistic weekly hours, ordered topics, a specific resource per topic, one deliverable per block and a review date. Without a deliverable it is not a plan, it is a wish list.

This is the skeleton, meant to be written into a file and versioned alongside your project.

And this is a complete instance of the template, for an application development profile. It serves as an example of the level of specificity, not as a universal plan.

How to spot a course that has not been touched for years (relevant when choosing your plan's resources): the engine version shown in the screenshots is several versions behind the current one; tools are used whose interface no longer resembles the real one; recent comments ask why a step no longer works; the syllabus ignores features that today are standard in the engine; and there is no visible update date anywhere. Any of those signals does not invalidate a theory course — normalization has not changed — but it rules out a product one.

Mistake 1: collecting courses. Enrolling in six courses and finishing none is a pattern so common that the platforms have a name for it. One at a time, with its deliverable, and until the deliverable exists the next one does not start.

Mistake 2: watching video without writing code. Watching someone write SQL produces the complete illusion of having learned, and that illusion dissolves the moment you have the cursor blinking on a blank query. Pause the video, type it yourself, and when it works, break it on purpose.

Mistake 3: searching a forum before the manual. The forum answer solves today's symptom; the manual teaches you where tomorrow's answer will be. And in a surprising percentage of cases, the forum answer is for a version that no longer exists.

Mistake 4: chasing the certificate instead of the project. It has been said already: a well-designed and documented schema in a public repository counts for more in a technical conversation than any completion diploma.

Mistake 5: studying an engine you are not going to use. Learning Cassandra "just in case" when you work with PostgreSQL is time that yields little. The legitimate exception is studying an engine from a different family in order to understand the contrast, which is exactly what module 3 of this course did: not to use Neo4j, but to see the relational model from the outside.

Mistake 6: not setting a time. "I'll study when I can" means not studying. Two fixed slots in the calendar, with a reminder, and treat them like a meeting.

Tip 1: always mix one slow resource with one fast one. A book under way (the 09-01 format) and a practice platform under way. The book gives judgment, the practice gives fluency, and each makes the other bearable.

Tip 2: write down what you learn. A short note per session — what I tried, what failed, what I understood — turns scattered hours into something you can consult. And if you dare to publish them, writing for others is the best detector of your own gaps in existence.

Tip 3: translate everything to your domain. The PGExercises exercises are about a sports club; rewrite three of them against BiblioRed. The translation is where the learning happens, because it forces you to understand the query instead of copying it.

Tip 4: use official syllabuses as checklists. A certification syllabus or a university course's table of contents is a very carefully worked inventory of what you need to know. Take advantage of them even if you do not enroll.

These exercises are about planning and real practice, not about memory. They have no single correct answer: the solutions are reasoned model answers, and yours will be different and can be just as good if the reasoning holds up.

Fill in the study-plan.yml template from section 9 with your real case. Minimum requirements:

1. Three specific weak points, citing the lesson where they appeared (not "SQL", but "in 07-04 I couldn't solve the same member's previous loan without a correlated subquery").
2. A justified target profile.
3. Weekly hours you can genuinely keep to, with a fixed day and time.
4. Four three-week blocks, each with named resources and a verifiable deliverable.
5. One success criterion per block that is not "having read it".
6. An intermediate review date and the questions you will ask yourself at it.

Find three online courses about databases or SQL: one from a university, one from a commercial platform and one free one from a community or a vendor. Without enrolling in any of them, in twenty minutes per course, fill in this table and decide which one you would take and why:

Add a final sentence: which part of that course you would skip, given what you already know after this one.

For one week, forbid yourself from searching the internet for any PostgreSQL doubt: the official manual only. Choose one section from the table in section 3 that you have not worked through (for example, Data Types or Indexes), read it in full and produce:

1. Five queries or DDL statements against BiblioRed that use something you have discovered in that section and did not know before.
2. One schema change in BiblioRed that you would make in light of what you read, with its justification.
3. Three things you thought you knew and that were wrong or incomplete.
4. An honest assessment: how much slower was it than searching the internet, and was it worth it?

These are model answers. What is assessed is the reasoning, not the agreement.

Solution 1 (model answer)

What makes this plan good is not its ambition, but three things: the weak points are cited by lesson, the deliverables are verifiable by a third party, and there is an explicit mechanism for cutting back at the review instead of abandoning.

Solution 2 (model answer)

A typical verdict, with the three usual profiles:

What I would skip in A: the programming projects, unless interested in building engines. In C: the introductory CRUD modules, already covered by 03-03 and 08-02.

The important conclusion of the exercise is usually this: after this course, most generalist SQL courses no longer give you anything, and your time yields far more in official documentation, graded practice and high-level university material.

Solution 3 (model answer, Data Types section)

1. Five new things applied to BiblioRed.

2. A justified schema change. Replace start_date/end_date in room_reservations with a tstzrange plus an exclusion constraint. Reason: the rule "two reservations for the same room cannot overlap" goes from being a check in the application — which fails under concurrency, exactly the problem in 06-02 — to being an engine constraint, which never fails. It is the same principle as 02-06: if the rule is about integrity, it lives in the database.

3. Three things I thought I knew and got wrong.

• I thought timestamp and timestamptz differed in that one stores the time zone. It does not store it: timestamptz normalizes to UTC on storage and converts to the session's zone on reading. That changes how you have to think about reports by time zone.
• I thought varchar(n) was more efficient than text in PostgreSQL. It is not; the limit is a constraint, not an optimization, and adding it without a reason only generates future migrations.
• I did not know range types or exclusion constraints existed, and I had been solving by hand a problem the engine solves declaratively.

4. Was it worth it? It was clearly slower: reading the whole section cost about three hours against the two minutes of a one-off search. It was worth it, and by a lot, because the three findings above cannot be searched for: I did not know they existed, and therefore I would never have formulated the query that would have found them. That is the argument for reading documentation in blocks instead of only consulting it: it solves the problem of the things you do not know you do not know.

This lesson can be summed up in four decisions.

The first: start with the official documentation, and study it in blocks. The PostgreSQL manual is not just a reference for looking up doubts: read section by section, with a query notebook of your own, it is the best available course on the engine, and it is free. The same goes for the MongoDB Manual, for the SQLite documentation — whose design documents are formative reading in themselves — and for Redis, Neo4j and Elasticsearch when you need them. The official documentation overrides any course.

The second: practice where you get corrected. PGExercises, SQLZoo, SQLBolt for the basics, HackerRank and LeetCode for volume and interviews. Choose the platform according to what stuck in your throat in module 7, and remember its limit: they teach you to query, not to design. Modules 4, 5 and 8 of this course have no equivalent platform, and their equivalent is designing things and submitting them to criticism.

The third: when you want depth, go to the university. The CMU Database Group's open material and Stanford's "Databases" series are at a level no commercial SQL course reaches, and they are the natural continuation of what 01-04 and 06-03 left hanging. Search for them by their exact title on the institution's site.

And the fourth, the one that decides whether the other three are worth anything: write your plan and give it deliverables. Four three-week blocks, one named resource and one thing built per block, two fixed slots in the calendar and a mid-way review to cut back without abandoning. Without deliverables there is no plan; with deliverables, in twelve weeks you have a public project worth more than any certificate.

And for the last time the warning that opens and closes this lesson: courses, prices, free tiers, certification catalogs and contents change without notice, and product courses age badly. Always check at the official source before enrolling or paying, and faced with any discrepancy between a course and the engine's documentation, the documentation is right.

You now have what to read and where to practice. The third vertex is missing: what with. Lesson 09-03 covers the tools you actually work with — the engines on your machine, the clients, the design tools, the migrations, the test data, the diagnostics and the backups — and includes the Docker Compose file that brings up in a single command the exact environment of the polyglot case study in 08-03.