第16編成以降は、1000系の投入と並行してリニューアル工事が実施された。施工第1号は第17編成で、同系列の投入より半年程早く登場した。抵抗制御の第1 - 9編成が運用終了したころ、第13 - 15編成も延命のために追加として車内の簡易改造工事（化粧板と床の張り替え）が行われた。第11・12編成は座席のモケット張り替えのみ、第10編成は廃車まで原型の配色の車内を保っていた。
系列による区別はなく1000系と共通で運用されたが、駅での旅客案内の都合上、ある程度はどの列車にどちらを充当するかは決まっていた。また、渋谷・吉祥寺の両駅では足元の緑色の乗車位置目標が、それ以外の駅では緑色の3扉車乗車位置が本系列となっていた。また、1000系の登場時にMT比の低さから空転が多かったため、雨天や降雪時の運用には優先的に本系列を投入していたことがあった。
製造当初は上り渋谷方先頭車クハ3750形がTc1、以下デハ3050形がM1、デハ3000形がM2、クハ3700形がTc2とされていたが、現在は下り吉祥寺方先頭車のクハ3700形がTc1とされ、以下デハ3000形がM1、デハ3050形がM2、デハ3100形がM、クハ3750形がTc2となっている。
登場当時は編成ごとのテーマカラーが先頭車前面のみであったが、後に側面の窓下にも前面と同一色の帯が入れられた。その後のCIマーク制定後には先頭車端部の窓上にマークを貼付し（旧来の社紋との並存時期もあった）、さらに2002年ごろには前面にも貼付した。排障器（スカート）は後付け設置である。冷房装置の交換も頻繁に行われ、集中型は鋼製のキセからステンレス製に、さらに6000系の廃車発生品を流用したものや1000系に搭載されたものを設計変更したものなどが存在する。
第1 - 15編成には水切りのみで雨樋がないが、第16 - 19編成にはさらに雨樋を装備する。第20編成以降では車体構造の変更に伴い水切りがなくなり、雨樋のみになる。
1975年（昭和50年）度から投入した（16・17編成が1975年製、18編成が1977年製、19編成が1979年製）。扉と主電動機の出力、台車などは第10 - 15編成と同じである。このグループより5両編成で新製され、すべての電動車が界磁チョッパ制御となる。また、デハ3000形のパンタグラフ搭載位置が、吉祥寺方から渋谷方に変更されている。第19編成では初めて側面にも行先表示器が設置された。このグループは2008年から2009年にかけて廃車されている。冷房装置は、第16・17編成は先頭車が集約分散式、中間車が集中式を採用したが、第18編成からは全車集中式とされた。
1969年（昭和44年）度に投入した。4両で新製された最後のグループである。扉と主電動機の出力、台車などは第10 - 13編成と同じである。このグループ以後は新製時から冷房装置を搭載する。2004年3月に第15編成が、同年11月に第14編成がそれぞれ廃車となったため、オリジナルタイプおよび（前面が普通鋼にリニューアル改造されていない）「ステンプラカー」は消滅した。冷房装置は5000系にも使用された6台/両の分散式（冒頭の写真参照）だが、後から組み込んだデハ3114・3115は集中式を1台搭載していた。
1967年（昭和42年）度に投入した。主電動機は直流複巻で出力120kW、歯車比が5.60から6.07に変更され、回生制動を採用した。台車はM車はTS-801を、Tc車は第1 - 9編成から捻出されたPIII-703を改造して使用した。Tc車は1985年以降にTS-821Aに交換された。このグループは第13編成が後述の第14・15編成とともに延命のための車内のみの簡易更新工事を1998年度に実施した。2000年（平成12年）に第10編成が、2003年（平成15年）に第11編成が、2004年に第12・13編成がそれぞれ廃車となった。こちらも非冷房で登場し、改造により冷房装置を搭載した。
MongoDBは、シャーディング（Sharding）というシステムによって水平スケーリングが可能である。これはBigTableやPNUTSのスケーリングモデルに非常に良く似ている。開発者はshardキーを選択し、このキーがデータをどのように分散させるかを決める。データ中のキーを元にデータを分散させるshardが決められる。（一つのshardは1つ以上のスレーブを持つマスタである）アプリケーションはいくつかの操作を行う際に、shardingされたクラスタと対話していることを認識している必要がある。例えば "findAndModify" クエリは、shardされたコレクションからクエリをするときにshardキーを含む必要がある。 アプリケーションは、mongosと呼ばれる特別なルーティングプロセスと対話する。このプロセスは、shardクラスタを単一のMongoDBサーバに見えるようにする。mongosプロセスはどのデータがどのshardにあるかを知っており、クライアントのリクエストを適切にルーティングする。すべてのリクエストはこのプロセスを通して流れる: リクエストやレスポンスを転送するだけでなく、必要に応じてマージやソートも行う。 mongosプロセスはいくつでも実行できるが、通常は1つのアプリケーションに対して1つが推奨される。