Database libraries are coming to KiCad...

[Doctorandus_P]

I just read a post about a preliminary implementation of database driven libraries in KiCad, and I've read here it's absence was an instant show stopper for a lot of people visiting the EEVblog forum.

Do note it's just a first / experimental implementation for the kicad-nightly version (So hopefully it will make it into the stable KiCad V7 version, which is expected around the end of this year or early next year.

https://forum.kicad.info/t/post-v6-new-features-and-development-news/32633/68

Also something to consider...
If this is / was the only show stopper to switch from some mega $$$ package to KiCad, then you may want to consider some donation. What if a (capable) implemenation of this (or another killer feature) can be implemented quicker, so KiCad becomes usable for you 1 or two years earlier?

There is commercial support for KiCad via the KiCad Service Corporation:
https://www.kipro-pcb.com/
And via them you can also sponsor priority development.
In this way, you can really get something back for your money, instead of (forced) yearly bills for mundane updates....

[nctnico]

Finally! 

I've read the documentation and it looks good. My only comment is that having a database is not just for larger companies or teams, it is also very usefull for small or single person companies. I have been using Orcad with a component database for >20 years and I never want to go back to the tedious situation where all the information of a part is stored in the parts library or sits 'hidden' in the schematic. A database makes it so much easier to 'share' components between designs as well. Define once, use many times with 100% assurance all the part information is correct so no nasty surprises after the board has been produced. It takes so much work away at the logistics side of things.

If this database feature works well, KiCad will start eating into Altium's market share for sure.

[SiliconWizard]

Well sure, the current library system on KiCad is not all that great.
Just hope they won't come up with a monster wuth this database thing. Keep it simple.

Oh, and one great feature that would definitely help migrating to KiCad would be import filters for parts (both symbols and footprints) from the major EDA such as Altium, Cadstar, Orcad.

[julian1]

I can see a few advantages in using a relational model to join and manage associated component attributes -  symbol, footprint, 3d model, documentation, etc.

But simple text files - even if denormalized, are one of the best features of Kicad imho. Leveraging existing source-control tools like git/github/gitlab for discovery, collaboration, and change management works well enough.

[nctnico]

I can see a few advantages in using a relational model to join and manage associated component attributes -  symbol, footprint, 3d model, documentation, etc.

But simple text files - even if denormalized, are one of the best features of Kicad imho. Leveraging existing source-control tools like git/github/gitlab for discovery, collaboration, and change management works well enough.

You shouldn't see a component database as part of a design or library. It is at a higher level where the logistics of producing a board are handled. A component database sits on top of the schematic and symbol & footprint libraries but isn't part of it.

[SiliconWizard]

I can see a few advantages in using a relational model to join and manage associated component attributes -  symbol, footprint, 3d model, documentation, etc.

But simple text files - even if denormalized, are one of the best features of Kicad imho. Leveraging existing source-control tools like git/github/gitlab for discovery, collaboration, and change management works well enough.

I agree with that, and whatever they do, I really hope the text formats will still be usable.

[nctnico]

AFAIK: git doesn't really care whether you store binary formats or text format. It treats everything as binary. Even with a text format, I don't see how you would be able to merge two versions of a schematic / PCB layout or see specific changes. Likely there is no pre-determined order in the KiCad files so how would a merge tool intended for software development deal with that? Unless ofcourse there is some kind of way KiCad can show 2 (or more) versions of the schematic / PCB layout and allow the user to choose what to pull in. The more expensive CAD packages have the ability to lock part of a design so a specific person can work on that part while locking others out. The changes can be merged later on.

Still putting schematics / layout in git is a good idea anyway for version control and easy sharing / backups.

[yaqwsx]

Even with a text format, I don't see how you would be able to merge two versions of a schematic / PCB layout or see specific changes. Likely there is no pre-determined order in the KiCad files so how would a merge tool intended for software development deal with that?

Since KiCAD 6 the file format is designed such that it preserves order so merging is indeed possible as the only thing that changes in the file are only descriptions of items that have changed. For footprints, it is actually quite useful to see the diff as they are small and the format is human-readable.