[eyko]

If you're going to treat logs as a db entry and afford them a schema, then by all means knock yourself out.

The main point he's trying to make is not just about the logs you wrote but about logs coming from other systems or services, e.g. monitoring kernel logs in your OS. As he rightly points out, one of the reasons is that logs are not an API.

> One reason this happens is that almost no one considers log messages to be an API, and so they feel free to change log messages at whim.

[gabereiser]

   create table log (dt timestamp not null primary key, msg text not null)

is usually all you need to start sifting through the haystack. Problem with this approach is if you aren't diligent, you'll end up killing you app AND you're db.

[sgarland]

You can’t use log timestamps as a PK; you’ll run into non-unique entries nearly immediately.

[gabereiser]

We already established that log sifting at scale isn’t productive nor does it work for reasons outlined in the article. This was just an answer to how to do it in a smaller scale. Yeah, primary key is going to give you problems, a simple index shouldn’t but the issue is this, logs are not event sources - or shouldn’t be. The only time you should be looking is when your looking for stack trace and even then there’s better options like sentry.